01
When it needs state
Attach a managed PostgreSQL, MySQL, MongoDB, Redis or Elasticsearch. Its connection URL lands in the app as a config var; the app finds it on the next boot.
Deploy
The push is the deploy.
An animated illustration of the App Builder: a prompt is typed into a text field, the Build it button is pressed, and the agent lists its plan — pages, data model, a managed database, a push to the repository — before starting work.
Describe an app and an agent writes it into your own GitHub repository. Or connect a repository you already have. Either way the push is the deploy: a build runs on your managed deploy server and a live address comes back.
01 How it works
Describe it. Watch it build.
A workspace binds a GitHub repository to a chat. You say what you want; the agent writes the code and pushes it; your deploy server builds the push and publishes the result.
Six steps: describe, plan, provision, build, deploy, live. A progress rail draws down the steps as you scroll.
- 01 Describe
Say what you want
Plain language. A landing page, a small API, a WordPress site. The agent asks what it still needs to know, then starts working in your repository.
- 02 Plan
The agent plans it
Pages, data model, the flow between them. Every step it takes is written into the chat, so nothing happens out of sight.
- 03 Provision
What it needs comes up
A managed database is provisioned with the app. Its connection URL is set as a config var, so the app finds it on the next boot.
- 04 Build
A push triggers a build
The agent commits to your GitHub repository. Your deploy server picks up the commit — clone, install, build — with no pipeline file to write.
- 05 Deploy
A release goes out
Config vars and the attached database carry over to the new release. The URL keeps working across the swap.
- 06 Live
A URL comes back
The app answers on its own address. Every later push updates it exactly the same way, and the address never changes across releases.
02 For developers
Push, and it goes out.
Connect a repository and Interlaken takes it from there — clone, install, build, run. Private repositories go through your own connected GitHub account, so no keys change hands.
- 01
Push to deploy
Pick a branch. Every commit on it is built and released; there is no pipeline file to write and no runner to maintain.
- 02
Private repositories, your account
Private repositories are cloned through your own connected GitHub account. No deploy keys change hands and nothing is copied into the platform.
- 03
Point at it, pick a runtime
Interlaken clones the repository, builds it and runs it. Web apps and services, WordPress sites — if it builds and listens on a port, it runs.
- 04
Logs and history in the console
Build output, deployment history and the app's own activity log sit on the same page as the app.
An animated sequence: a commit changes the checkout total, git push runs, the deploy log shows the build and release steps, the app comes up at its live URL, and the deployment history lists the releases behind it.
03 Keep going
It grows with you.
Your app is not sitting in a black box. Underneath it are the same primitives everything else on Interlaken runs on — and the day you need one of them, it is a page away, not a migration away.
02
When it needs settings
Edit environment variables in the console. They are written to the running machine and baked in for its next boot, so nothing drifts.
03
When a release is bad
Every deploy is recorded with its build log. Redeploy an earlier version and the app rolls back to it — the URL keeps answering throughout.
04
When it needs your name
Every app starts on your deploy server's app domain. Point your own domain's DNS at the server, add it to the app, and it answers there too.
Underneath
-
Real machines
Apps run on virtual machines, Firecracker microVMs and containers you can resize, snapshot, open a console on, and place yourself.
-
Real networking
Private networks and subnets, load balancers that speak TCP through HTTP/3, public addresses and routed egress — the fabric the platform runs itself on.
-
Managed state
PostgreSQL, MySQL, MongoDB, Redis and Elasticsearch as managed services, plus replicated block volumes and S3-compatible buckets.
04 Questions
Before you start.
The short answers. The long ones are a page in the console.
No. In the App Builder you describe the app in a chat and an agent writes and deploys it. The code lives in your own GitHub repository the whole time, so you can read it, edit it, or hand it to a developer whenever you want to.
Web apps and services from a Git repository, WordPress sites, and apps the App Builder writes for you. If it builds and listens on a port, your deploy server can run it.
Yes — point its DNS at your deploy server and add the domain to the app. For traffic you route through an Interlaken load balancer, the certificates service holds the TLS key pairs it terminates with.
See custom domainsYes. Managed PostgreSQL, MySQL, MongoDB, Redis and Elasticsearch attach in one step and arrive as a config var.
See attached databasesThe deploy server picks up the commit, builds the app and releases it. Config vars and attached databases carry over, and the URL keeps working across the swap.
Watch a pushYes. Redeploy any earlier version from the deploy history and the app rolls back to it.
See rollbacksNothing to install
Start with one sentence.
Create an account, describe what you want to run, and let the agent take the first pass. You pay for what you use.