Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Building a modern alternative to cPanel – looking for feedback from the LET community

1…5678911»

Comments

  • @itzsenu said:
    im still missing the actual technical details. i want to know what actually happens under the hood.

    1. account isolation

    you said every account gets a separate linux user and chroot.

    • what else is used besides chroot?
    • namespaces?
    • separate uid?
    • separate php-fpm process?
    • what stops account a from reading account b?
    • symlinks?
    • hardlinks?
    • /proc?
    • /tmp?
    • sockets?
    • dropped capabilities?
    • show a sanitized example config.

    if a wordpress plugin gets fully compromised, what can the attacker access?

    1. cgroups / resource limits

    you mentioned:

    CPUQuota
    MemoryMax
    IOWeight
    IOReadIOPSMax
    IOWriteIOPSMax
    TasksMax

    how are these actually applied?

    • cgroup v1 or v2?
    • what does the hierarchy look like?
    • show systemctl show output or /sys/fs/cgroup.
    • how does HPanel -> database -> systemd ->kernel work?
    • what happens when a limit is reached?
    • do php/cron/ssh child processes get limited?
    • do limits survive reboot?
    • can limits change while processes are running?
    1. source of truth

    you said postgresql is the source of truth.

    • what tables store accounts?
    • domains?
    • dns?
    • php settings?
    • limits?
    • ssl?
    • mail?
    • what happens if someone manually edits nginx or php-fpm?
    • does HPanel detect drift?
    • are generated configs deterministic?
    • are configs validated first?
    • what happens if reload fails?
    • does it roll back?
    • what happens if the server dies halfway through?
    1. production scale

    you said 60 accounts is the current production peak.

    what was the server?

    • cpu?
    • ram?
    • storage?
    • traffic?
    • php requests/sec?
    • database load?
    • disk iops?
    • cpu usage?
    • ram usage?

    what was the first bottleneck? and have you actually tested more than 60 accounts?

    1. backups

    you mentioned rsync and mysqldump --single-transaction.

    • where are backups stored?
    • separate server?
    • separate failure domain?
    • encrypted?
    • versioned?
    • retention?
    • checksums?
    • corruption detection?
    • restore tests?
    • alerts when backups fail?

    when was the last successful restore test? having a backup and successfully restoring one are two different things.

    1. disaster recovery

    you said a full account can be restored to a fresh server. okay. production server gets completely destroyed. only the off server backup survives. can you restore all of this?

    • HPanel config
    • accounts
    • files
    • databases
    • database users
    • dns
    • mailboxes
    • mail config
    • ssl
    • cron
    • permissions
    • ownership
    • php versions/settings
    • resource limits
    • firewall config
    • domains/subdomains

    without manually rebuilding everything? have you actually tested this on a clean server?

    • restore time?
    • automation percentage ?
    • what failed?
    1. cpanel / directadmin migration

    for cpanel:

    • .htaccess?
    • apache modules?
    • php extensions?
    • custom php settings?
    • cron jobs?
    • mailboxes?
    • passwords?
    • dns?
    • ssl?
    • database users?
    • permissions?
    • custom nginx/apache config?
    • cpanel plugins?

    what happens when HPanel finds something unsupported?does it stop or continue and report it? also how do you detect .htaccess rules which cannot be converted to nginx?

    1. concurrent operations

    you mentioned a global i/o lock and atomic database queue.

    • global lock or per account?
    • can two accounts migrate at once?
    • can backup and migration run together?
    • what happens if an account changes during backup?
    • what happens if migration dies halfway?
    • what happens after power loss?
    • can a job run twice?
    • how are failed jobs recovered?
    • idempotency?
    • config versioning?
    1. panel compromise

    you said a fully compromised root-level panel basically means root access. what else is protecting the system?

    • what runs as root?
    • what runs unprivileged?
    • public site separated from management?
    • public api?
    • can customer websites access the api?
    • authentication?
    • authorization?
    • rate limiting?
    • mfa?
    • scoped api tokens?
    • audit logs?
    • session protection?
    • plugin sandboxing?
    • independent security audit?

    if HPanel gets compromised, can the attacker also grab the backup credentials?

    1. HPanel attack surface

    what is HPanel built with?

    • language?
    • framework?
    • dependency scanning?
    • static analysis?
    • security testing?
    • secret storage?
    • database credentials encrypted?
    • password hashing?
    • encrypted credentials?
    • ssh/api credential protection?
    • security disclosure process?
    • cve history?
    • patch time for critical bugs?
    1. multi tenancy

    what stops one customer from destroying the node for everyone else?

    • all ram?
    • all cpu?
    • all processes?
    • all disk i/o?
    • all inodes?
    • millions of files?
    • network connections?
    • dns?
    • /tmp?

    what noisy neighbor protections exist?

    1. php fpm
    • separate pool per account?
    • separate uid?
    • separate socket?
    • separate limits?
    • can pool a access account b?
    • how are php extensions controlled?
    • dangerous functions?
    • multiple php versions?
    • how are php upgrades handled?
    1. database isolation
    • separate databases per account?
    • separate database users?
    • can account a connect to account b?
    • how are credentials stored?
    • cpu limits?
    • ram limits?
    • i/o limits?
    • what happens when one database goes crazy?
    • how are consistent backups made?
    • how are restores tested?
    1. dns
    • what dns server?
    • what backend?
    • generated from postgresql?
    • how are changes pushed?
    • what happens when generation fails?
    • dnssec?
    • rollback?
    • version history?
    • what prevents unauthorized changes?
    1. mail

    if HPanel handles mail:

    • which mta?
    • which imap/pop3 server?
    • mailbox isolation?
    • spam limits?
    • abuse limits?
    • sending limits?
    • dkim?
    • spf?
    • dmarc?
    • mail backups?
    • what happens if one mailbox gets compromised?
    1. ssl
    • letsencrypt automated?
    • automatic renewal?
    • what happens when renewal fails?
    • encrypted certificate storage?
    • can customer processes access private keys?
    • automatic nginx rollback?
    1. updates / rollback
    • how does HPanel update?
    • atomic updates?
    • rollback?
    • what happens if an update dies halfway?
    • can one bad update take down every site?
    • database migrations backward compatible?
    • zero-downtime updates?
    1. monitoring

    what happens when:

    • nginx dies?
    • phpfpm dies?
    • postgresql dies?
    • dns dies?
    • disk fills?
    • inodes hit 100%?
    • backup fails?
    • ssl renewal fails?
    • config generation fails?
    • migration fails?
    • network dies?

    does HPanel detect it automatically?

    does someone get an alert?

    or do customers have to start screaming first?

    1. benchmarks

    this was question #10 from my original post. i don’t need a "HPanel is faster than everything" benchmark. i want the actual HPanel numbers.

    • cpu overhead
    • ram usage
    • account creation time
    • domain creation time
    • php performance
    • database performance
    • max tested accounts
    • backup speed
    • restore speed
    • migration speed
    • server rebuild time
    • config generation time
    • concurrent operations
    1. reproducibility

    the easiest way to prove most of this would be one public test.

    something like:

    fresh debian
    -> install HPanel
    -> create 10/50/100 accounts
    -> apply cpu/ram/iops limits
    -> run workloads
    -> kill services
    -> break configs
    -> run backup
    -> destroy server
    -> reinstall
    -> restore
    -> check websites
    -> check databases
    -> check dns
    -> check limits

    post the results.

    i said i want to see the difference between "this is how HPanel is designed" and "we tested it, here are the results."

    show the receipts.

    i swear i never used AI to structure the message. i did it manually like hpanel, but without vibing the message.

    care to answer these questions @HPanel ?

  • The backup/restore bit is the one that stuck with me. I once had a panel reporting clean backups for months, then the one time I actually needed one the restore fell over on a permission mismatch — and that was the day I stopped trusting a green tick. Now I only count a backup if I've restored it somewhere else and actually logged in afterwards. Curious how you handle that part, is restore testing something you run on a schedule, or only after something goes wrong?

  • Hostinger offers hPanel.
    is this the same?

  • AndruAndru Member

    @JasonM said:
    Hostinger offers hPanel.
    is this the same?

    No, this is just a AI SLOP, cPanel wanabe.

  • HPanelHPanel Member, Host Rep

    @JasonM No, it's not related. Hostinger's hPanel is the panel they use for their own hosting customers, while HPanel is a self-hosted control panel you install on your own server, made by Hostlic Webhosting Ltd. More details are at https://hpanel.net/

  • Why not just contribute to this free, open source panel instead?
    https://github.com/hestiacp/hestiacp

  • HPanelHPanel Member, Host Rep

    @itzsenu @edmarhub Fair questions, here are the answers point by point.

    1. Account isolation: Every account runs as its own Linux user with its own PHP-FPM pool, and PHP can only reach that account's own files. Shell-command functions are disabled, and chroot can also be turned on per account. A compromised plugin only reaches that one account.

    2. cgroups / resource limits: We use cgroup v2 through systemd, with one slice per account for CPU, RAM, I/O and process limits. Changes apply live and stay after a reboot. When an account hits a limit, only that account slows down.

    3. Source of truth: The panel database holds everything, and server configs are generated from it. Every config is tested before it's loaded, so a bad change never goes live. Manual edits are replaced on the next update, and custom rules have their own place in the panel.

    4. Production scale: We run 60 accounts on one live production server and have tested more than 500 accounts on a single server.

    5. Backups: Backups go to a Hetzner Storage Box, Amazon S3, S3-compatible storage, Google Cloud or local disk, with automatic retention. Every backup is checksummed and verified before restore. Admins are alerted if a backup fails.

    6. Disaster recovery: A full-server backup plus emergency restore rebuilds everything on a fresh server automatically: accounts, files, databases, DNS, mail, SSL, PHP settings, limits and cron. A full end-to-end restore test with published timings is part of the public test in #20.

    7. cPanel migration: Domains, files, databases and users, mailboxes with their passwords, DNS and PHP versions migrate automatically, and SSL is issued fresh. Standard WordPress and app rewrites work natively on nginx, and custom rules go into Site Rules. Anything unsupported is listed in the migration report, and the migration keeps going.

    8. Concurrent operations: Heavy jobs run one at a time and are claimed atomically, so a job can never run twice. Interrupted jobs are marked failed and are safe to retry. Database backups are consistent even while the site is live.

    9. Panel compromise: The panel runs on its own ports, separate from customer sites, and can be firewalled to admin IPs. It has bcrypt passwords, 2FA, role-based access, rate limiting and audit logs. Customer websites have no access to the panel API.

    10. Attack surface: HPanel is built with Node.js, Express, React and PostgreSQL. Updates are signed and checksum-verified, passwords are hashed with bcrypt, and stored credentials are encrypted. Security reports go to [email protected].

    11. Multi-tenancy: Each account has its own CPU, RAM, process and I/O limits, plus disk and inode quotas and MySQL per-user limits. Each account has its own temp folder, and Fail2Ban and ModSecurity protect the whole server.

    12. PHP-FPM: Each account gets its own pool, user, socket and limits. PHP 7.4 to 8.4 can be chosen per domain, extensions are set per account, and dangerous functions are disabled.

    13. Database isolation: Every database and database user belongs to one account and can only access that account's databases. Per-user MySQL limits stop one database from hurting others, and backups are taken consistently.

    14. DNS: BIND9 zones are generated from the panel database and tested before every reload. If a change fails, the last good zone stays live. DNS cluster nodes stay in sync, and only the owner or an admin can edit a zone.

    15. Mail: Mail runs on Postfix and Dovecot, with DKIM, SPF and DMARC set up automatically. SpamAssassin, ClamAV and Fail2Ban protect it, and mailboxes are included in backups. A compromised mailbox can be reset or suspended from the panel in one click.

    16. SSL: Let's Encrypt certificates are issued and renewed automatically. If a renewal fails, the current certificate stays active and the panel shows the status. nginx is always tested before it reloads.

    17. Updates / rollback: Updates are signed and verified, health-checked after install, and rolled back automatically if something fails. Customer sites keep running during a panel update, and auto-update can be turned off.

    18. Monitoring: Every 5 minutes HPanel checks nginx, PHP-FPM, PostgreSQL, MySQL, mail and DNS services, plus disk usage. Admins get email or webhook alerts when something goes down and again when it recovers. Backup failures and malware detections are alerted too.

    19. Benchmarks: On an idle server the panel itself uses around 80 to 120 MB of RAM. We'll publish the full numbers (account creation, backup, restore and migration speed, config generation and concurrency) together with the public test in #20.

    20. Reproducibility: Agreed, that's a good test. We'll run it on a fresh Debian server, from install all the way to restore, and post the results here as soon as it's done.

  • aaPanel_teamaaPanel_team Member, Patron Provider

    Why not choose to contribute to this free, open-source project?
    https://github.com/aaPanel/aaPanel

  • Why not choose to contribute to this free, open-source project?
    https://github.com/openssh/openssh-portable

  • HPanelHPanel Member, Host Rep

    @souhaojicom That permission problem doesn't happen on the HPanel: a restore puts website files and mail back with their correct owners, and we verify it by restoring an account and sending a test mail to it. Automatic scheduled test-restores are coming in an upcoming release too.

  • HPanelHPanel Member, Host Rep

    @aaPanel_team Why would we contribute to your project when you are selling your own panel too? Your panel is totally useless, and many of your users have already moved to HPanel. This thread is for feedback on HPanel, so please don't use it to advertise your product. Kindly stop spamming here.

  • AndruAndru Member

    @HPanel said:
    @aaPanel_team Why would we contribute to your project when you are selling your own panel too? Your panel is totally useless, and many of your users have already moved to HPanel. This thread is for feedback on HPanel, so please don't use it to advertise your product. Kindly stop spamming here.

    LOL :D :D :D :D
    Bull$hit: many of your users have already moved to HPanel

  • woinokizwoinokiz Member
    edited November 4

    Believe me use 1panel instead of whatever these ai made arse are claiming to be

    Thanked by 1vanamees
  • HPanelHPanel Member, Host Rep

    @woinokiz People who can't build anything themselves are always the loudest at barking at others. HPanel is built by real developers, and if you have real feedback we're happy to hear it.

  • @HPanel said:
    @woinokiz People who can't build anything themselves are always the loudest at barking at others. HPanel is built by real developers, and if you have real feedback we're happy to hear it.

    How many security audits have been done? Who have done them?

    Thanked by 1forest
  • @HPanel said:
    @woinokiz People who can't build anything themselves are always the loudest at barking at others. HPanel is built by real developers, and if you have real feedback we're happy to hear it.

    Real devs my ass

    Thanked by 2Obelous COLBYLICIOUS
  • @Chievo said:

    @HPanel said:
    @woinokiz People who can't build anything themselves are always the loudest at barking at others. HPanel is built by real developers, and if you have real feedback we're happy to hear it.

    How many security audits have been done? Who have done them?

    Claude

  • @Chievo said:

    @HPanel said:
    @woinokiz People who can't build anything themselves are always the loudest at barking at others. HPanel is built by real developers, and if you have real feedback we're happy to hear it.

    How many security audits have been done? Who have done them?

    This. I would be far more trusting if any reputable red team pentested your software.

Sign In or Register to comment.