The HYEHOST panel is built as a custom control platform rather than a thin skin over someone else's billing area. That means the architecture underneath matters: it needs to support multiple frontend services, reliable database access, private backend communication and predictable automation for hosting actions.
Why PostgreSQL
PostgreSQL is the source of truth for structured panel data: customers, services, virtual machines, order state, automation jobs, network allocations, product options and audit-friendly records. Hosting panels are state-heavy systems, so the database needs to be boring, consistent and well understood.
Why PgBouncer sits in the middle
Multiple panel frontends can create a lot of database connections if every request talks directly to PostgreSQL. PgBouncer gives us a controlled pooling layer. Frontends can scale horizontally while the backend database is protected from unnecessary connection churn.
- Frontend nodes connect to PgBouncer instead of opening unlimited direct PostgreSQL sessions.
- PgBouncer pools and reuses backend database connections.
- Connection limits are easier to reason about during traffic spikes.
- Maintenance is cleaner because the database layer has a defined access path.
WireGuard between layers
Our frontends speak to backend database services over WireGuard-protected private paths. That means database traffic is not treated like ordinary public web traffic. It has a narrower route, encryption between nodes and a clearer trust boundary.
frontend nodes
-> WireGuard private network
-> PgBouncer pool
-> PostgreSQL backend
Why customers should care
This is not just internal engineering trivia. The same design principles show up in customer infrastructure: keep public web entry points separate from private database paths, avoid exposing management services directly, use connection pooling where many app workers hit one database and use VPN-style links when services live on different hosts.
