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 Variables view 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.