Hub Cloud and on-prem
A dedicated Docker environment for every org. Hub manages the host while your team and its coding agents work with apps, instances, releases, access, environment, logs and URLs.
Small custom software should be allowed to behave like normal software. A web server that stays running, a worker, a database beside the app, uploads, scheduled jobs, open connections.
Hub gives those workloads a normal Docker host instead of a serverless shape. No function timer waits to stop the process; containers run until the app is redeployed, stopped or removed.
Your org gets a host of its own. You do not manage virtual machines, reverse proxies, certificates, container networks or deployment scripts for every small app.
Inside the hostOrg host ├── customer-portal/prod │ ├── web │ ├── worker │ └── db ├── customer-portal/staging │ ├── web │ └── db └── inventory/prod └── web
One org, one host, many independently managed app instances. Each instance has its own URL, environment, access rule, releases, logs and named volumes. What deploys and how: Deploy.
Data stays in named volumes. They survive deploys, restarts, environment changes, stop and start, and rollbacks.
A database is another service in the app's compose file rather than a proprietary Hub resource.
Not built yet: nothing backs up volumes. Keep your own backup of anything that matters. backups: coming soon
Keep the Hub workflow inside your infrastructure. A packaged self-hosted edition does not exist yet.
Teams that need the apps and their data inside their own network, next to internal services, under their own data-location rules, can talk to us. The deployment and support model is agreed case by case while on-prem access stays limited.
Dedicated and simple. One host is one org's failure domain.
Hub does not provide automatic horizontal scaling, multi-region failover or managed high-availability databases. The model is for custom team software, where predictable deployment and control matter more than internet-scale architecture.