How AppHaven runs your app
This page is the platform in one picture: what happens to your code after a push, where your app actually runs, what is isolated from what, and which responsibilities are AppHaven's versus yours. If you're deciding whether to run something that matters on AppHaven, start here.
Everything runs in containers, in a machine of its own
Every service you declare in the manifest runs as a container: either an image AppHaven builds from your repository or one it pulls for you. You describe the containers; AppHaven runs them.
What makes the runtime different is what's around those containers: each deployment gets its own virtual machine. Your production deployment, every preview, and every other customer's app each run in a separate machine with its own operating system. Your app never shares a kernel with anyone else's code, and the CPU, memory, and storage you size it with belong to it.
Builds are isolated the same way: each build from source runs in a fresh environment created for that one build and destroyed when it finishes.
Networking
Inside a deployment, your services share a private network and reach each
other by name: a service named api listening on 8080 is http://api:8080
to its neighbours, and a database named db is db:5432. See
Services: networking.
From the outside, exactly one thing is reachable: the ports you declare in the manifest, served on your app's URL over HTTPS. AppHaven terminates TLS and manages the certificates; there is nothing to configure and nothing to renew.
Between deployments, the rule is simple: deployments cannot reach each other. Not other customers' deployments, and not your own: a preview can never call into production. This separation is enforced by the platform underneath your app, not by rules inside it, so even a misbehaving or compromised application stays in its own box.
Your app can make outbound requests to the internet (calling third-party APIs, sending email through a provider, fetching webhooks) like it would anywhere else.
Your data
When you create an app you pick its region, an EU datacenter, and that choice is fixed for the app's life. AppHaven is a European company running on European infrastructure; your data staying in the EU is a structural property of the platform, not a setting.
Each deployment owns its persistent state: the volumes you declare and the storage behind any managed database. That state survives every redeploy, and it is backed up automatically: databases continuously, with point-in-time recovery, and all persistent data in nightly snapshots kept outside your app's environment, where the app itself can't touch them. The full story is in Backups & recovery.
What AppHaven manages and what you manage
| AppHaven manages | You manage |
|---|---|
| Building images from your repository | Your application code and Dockerfile |
| Running your containers, restarting them if they crash | Your manifest: which services run, with what storage and configuration |
| Your app's URL, HTTPS, and certificates | Your domain's place in your product (what you link where) |
| Provisioning and operating the managed database, including its credentials | Your database schema and migrations |
| Backups and point-in-time recovery | Deciding when to ship, and what to roll back to |
| Storage for volumes and databases | What your app writes, and where it mounts volumes |
| Isolation between deployments | Authorization inside your app: who may do what |
| Project access control machinery (roles, invites) | Who is in your project, and with which role |
In short: AppHaven is responsible for the platform your app runs on; you stay responsible for what the app is.
Production and previews are the same thing
A preview isn't a stripped-down mode. Deploy any branch and it gets the full treatment: its own virtual machine, its own database, its own volumes, its own URL. Production is simply the deployment of your production branch. This is what makes the preview-first workflow safe: an experiment runs on real infrastructure without being able to touch real data.
Where to go next
- What happens when you deploy: the lifecycle, step by step.
- Backups & recovery: what is protected, and how to get data back.
- Security: secrets, credentials, and the isolation model.
- CPU, memory & storage: sizing your app.