You wrote the app.
We run the rest.

No. The build detects your stack itself and works out how to build it, which covers most stacks with nothing to configure. Already keep a Dockerfile and would rather use it? Choose the dockerfile build type and we will.

Yes, and there is nothing to set up: backups are on or off per database, stored by Maxlayer in our own storage on the server your database runs on, and they cost an extra 30% of the database's plan while on. Two limits we would rather state than have you discover: Redis cannot be backed up, and restoring is manual — a backup is a dump file, and putting it back is something you do.

No, and that is most of the point. The organization API key that deploys your apps authorizes chat completions, embeddings, images and video, every call draws from the same prepaid credit as your containers, and the usage shows up in the same dashboard. The public model catalogue lists every model we sell, its capabilities, and what it charges — a rate per million tokens where the model has one, and the provider's own price per image or per second where it does not — so you can read the price before you send a request.

Then that is what you pay for. Nothing here is a bundle: credit is credit, and it is drawn by whatever you actually run. An account that never calls a model is never charged for one, and an account that only calls models never has to deploy anything. All-in-one means one place and one balance, not a package with parts you did not ask for.

Yes. The Logs tab gives you the container's runtime output alongside the build and deploy output for each release. It is there to help you diagnose a running service; if you need long-term retention, aggregation, or alerts, keep sending application logs to the log system you already use.

Yes, per container: CPU, memory against the limit, and network and disk throughput both ways. This answer used to be no — the readings were not sampled reliably enough to draw, and we would rather leave a gauge out than fill it with a guess. They are now. You also still get the thing that matters most when something is wrong: the restart count and the exit reason. A container killed for exceeding its memory limit says exactly that, rather than leaving you to look up what exit code 137 means.

Not yet — gitlab.com only. A self-managed instance lives on its own hostname and the connection has nowhere to put it. GitHub and gitlab.com both work today; Bitbucket is in the interface but the adapter behind it is not built, so it is not offered. If your repository is somewhere we do not reach, building the image yourself and giving us that is the way in.

Yes, and it is deliberately more than a toggle: publishing a database is confirmed and recorded, because it moves a port from private to reachable. Two things worth knowing before you do. Once open, the port is reachable by anyone who finds it — narrowing that is a firewall rule on the server, not a setting here — and it answers on a hostname in our zone rather than the server's address, which is DNS only. The name means your connection string survives the database moving; it does not hide the machine.

Your apps stop, and they start again when you top up. There is no auto-recharge yet, so a balance heading for zero is something to watch rather than something we quietly cover — the billing page shows the balance and what it is burning per hour. Nothing is deleted when you run out: the app, its configuration, its databases and its history are all still there.

Marking a variable secret makes it write-only in the dashboard and API after it is saved. Your application receives it; the interface returns a masked value instead. Replace a secret whenever you need to, and editing other variables leaves it untouched.

Yes. The dashboard is one client of a documented REST API — creating apps, updating environments, triggering deploys and reading logs are all endpoints. Issue a key with the role that job needs and nothing more.

Whoever you decide. Viewers read, developers deploy and change configuration, admins manage members and keys, owners own the organization. Roles are enforced by the API on every request, not merely hidden in the interface.

Your application is a container built from your repository, so it runs anywhere else that takes containers. No proprietary manifest to unpick, nothing to rewrite. We would rather earn the next top-up than make leaving expensive.