clundra
Documentation

How apps work

An app is the unit you deploy, share and go back to. Everything else on these pages is a property of one.

One app, one service, one URL

An app runs on its own machine — isolated from every other app, with its own filesystem and its own network namespace. Inside it runs one service, optionally alongside a managed Postgres, on one URL. That is the whole shape of the thing.

That covers the software this is built for: a frontend with its API routes behind it, an internal tool, a small product. The service and its database go back together, because they are one app. How the service is reached, and the port and naming rules it lives under, is on Services.

Splitting an app across several services — a frontend and a separate API as siblings behind one URL — is on the roadmap, not in the product today.

Existing and running are different questions

An app has an identity from the moment you create it — before anything has been built, and before anything is serving. Its status is what tells you whether it is up: creating, deploying, running, or failed. A failed app also carries the reason, naming the service that failed, and that reason is cleared when the app comes up again — so it describes the present, not a history.

One region

Apps run in Falkenstein, Germany (fsn1), on EU infrastructure. There is one region, so there is nothing to choose — it is stated here rather than offered as a setting.

There is no size to pick

You will not find a CPU or memory dial, a disk size, a lifetime, or a health-check path. Those are deliberate absences rather than settings we have not built yet, and the reason is the same for all of them: each one is a decision you would have to make correctly, forever, about software whose shape changes every week.

  • No CPU or memory choice. An app gets what it needs to run: memory follows what it actually uses and is handed back when it does not, up to a ceiling you never have to pick. There is no tier to outgrow and no under-provisioning to diagnose. The app's Settings page shows what it is using and what that ceiling is — as a read-out, not a dial.
  • No disk size. Storage comes with the app, and your database and files persist across deploys without being sized up front.
  • No lifetime. An app is not a job with a deadline. It runs until you delete it.
  • No health-check path. An app is up when its service answers on its port. There is nothing to configure and nothing to get subtly wrong.
An app can optionally pause when nothing has reached it for a while and wake on the next request. That is a latency behaviour, not a size setting — see Limits.

Next

A service comes from a Git repository or a container image. Sources covers both, and what gets detected for you.