Core concepts
A handful of ideas explain how everything on Orizon fits together: projects, deployments, environments, and nodes.
Projects
A project is one app. It has a source (a connected GitHub repo, a Git URL, or uploaded code), a production branch, a set of environment variables, a primary domain, and a history of deployments. Project IDs look like proj_…. Everything you manage in the dashboard hangs off a project.
Deployments
A deployment is one build-and-release of a project. Each deployment is tied to a commit (or an uploaded snapshot) and moves through a set of statuses:
- queued — accepted, waiting for a build slot.
- building — the stack is detected and built into an image.
- deploying — the new release is rolled out and routed.
- healthy — live and serving traffic.
- failed — the build or rollout did not succeed; the previous healthy release keeps serving.
- rolled_back — a previous deployment was promoted back to live.
Builds happen on a build node and the resulting image is pulled and run on a runtime node, so a failed build never takes down what's already live. You can roll back to any earlier healthy deployment from the dashboard or API.
Environments & variables
Each project has a set of environment variables— secrets and config injected into your build and runtime. They're encrypted at rest, masked in the UI, and never returned in plaintext over the API. Changing them triggers a redeploy. A global Environment Variablesview lets you browse and search variables across every project, and you can export a project's .env after an email-OTP re-auth.
Nodes
Your apps run on real servers Orizon calls nodes. On the shared Go plans your app runs on shared infrastructure; on Plus plans it runs on a dedicated server. Internally Orizon separates a build node (which compiles your code and pushes an image) from a runtime node (which pulls and runs it), but you never have to think about that split — it just makes deploys fast and isolated.
The deploy flow
Putting it together: you connect a source to a project → a push (or a CLI deploy, or an API call) creates a deployment → Orizon detects the stack, builds an image on the build node, and rolls it out on the runtime node → Caddy routes your domains to it and provisions TLS → the deployment goes healthy and your URL is live.