Hakopod Cloud is planned around a straightforward job: deploy an application from Git, give it an HTTPS address, connect its private dependencies and choose predictable resource limits. It is in development.
Updated September 30, 2026: Cloud database access depends on workspace eligibility, capacity and the corresponding operator rollout. Signup does not guarantee compute or database provisioning. Check the current database guide before planning a deployment. Paid checkout remains closed.
Earlier update, September 28, 2026: Cloud account signup is open. Compute access depends on your workspace; account creation does not reserve capacity. Paid checkout and the managed database preview are not enabled yet. The operating boundaries below still apply.
Updated September 24, 2026: BYOD Starter is planned at $5/month for one server; BYOD Team at $15/month for three servers and unlimited members. Extra servers will cost $4/month each. Paid checkout is not open yet, and hosted compute will be priced separately. See pricing for available versus planned features. Bringing a node does not change Cloud’s public networking boundaries. See the BYO node guide for the intended responsibilities.
Public SMTP servers, SFTP endpoints and custom TCP listeners need their own routing, capacity and abuse controls. Those workloads belong on self-hosted Hakopod installations.
A hostname does not route every protocol
HTTP carries a host name in the request, so an ingress can send different domains to different applications on shared public ports. Arbitrary TCP traffic does not provide an equivalent universal routing field.
SMTP makes the difference concrete. The server sends a greeting before a normal client sends a recipient address, and one connection may carry messages for multiple destinations. Submission can also depend on authentication rather than the destination domain. A shared SMTP service needs protocol-aware authentication, routing and abuse handling; it is not just an HTTP proxy with a different port number.
Some TLS protocols provide useful routing information, but that does not make them interchangeable. A product that says “map any port” also needs to define who owns the listener, how protocols share it, how capacity is allocated and what happens when someone misuses it.
Self-hosted gives the operator that decision
On self-hosted Free or licensed Hakopod, an administrator can provision a public TCP listener and enable the port for application mappings. Deployment does not automatically alter host listeners or cloud firewall rules.
This keeps a platform-wide operation with the person responsible for the installation. An application can request an approved mapping; it cannot assume ownership of a host port simply because its container listens there.
A customer-owned installation on AWS, GCP or Azure follows the same self-hosted product boundary. Paying for operations does not turn that dedicated environment into the shared Cloud service, and a license does not override the installation’s networking policy.
Private TCP still belongs in both models
An HTTP application often needs PostgreSQL, a queue or another internal API. Keeping arbitrary public listeners out of shared Cloud does not remove those dependencies.
Hakopod’s private service ports and scoped virtual networks describe these connections explicitly. Services can share an approved segment, expose declared ports inside that scope and restrict which peers reach them. Public application traffic follows the HTTP/HTTPS ingress path separately.
Application email can use an external delivery provider. The platform’s account and alarm email configuration is also separate from allowing customers to run inbound SMTP servers.
What still needs verification before launch
The engine already rejects public TCP mappings in managed-cloud mode during planning, acceptance, rollback and reconciliation. That is an enforced product boundary. It is not the whole work required to open a shared hosting service.
Opening Cloud requires account-level admission and capacity enforcement, including rollout headroom and builds. Per-application CPU and memory ceilings do not add up to a customer subscription limit by themselves. Inbound listener restrictions also do not prevent outbound email abuse.
Isolation, upgrades, TLS renewal, recovery, support access and exhaustion behavior need acceptance in the environment that will host customers. The present self-hosted trust model is one operator organization with trusted developers; unrelated tenants need a broader operational and isolation review.
See Cloud for current beta access and self-hosted Hakopod for the operator-controlled path. The networking guide explains the controls implemented today.