Concepts
Glossary
Definitions of the terms NebulaCtrl uses in the console, the API and these docs, each linked to the page that explains it.
The console, the API and these docs use each term below in exactly this sense. Terms are in alphabetical order.
| Term | Definition | Read more |
|---|---|---|
| Activation | The moment an environment's stable entry point starts sending traffic to a release, which completes a deployment's move from candidate to live. | Deployments |
| Agent | The process in a cluster that receives desired state from the control plane, reconciles the cluster toward it, and reports nodes, workloads, logs and events back. Its connection is outbound only. | How NebulaCtrl works |
| Agent update | A change of the image a cluster's agent runs, started by you. A new agent that never reports in within a fixed deadline is rolled back to the previous image. | Update an agent |
| Approval | A sign-off a protected environment requires before a deploy, rollback, promotion or change set takes effect. | Change sets and approvals |
| Audit event | An immutable record of a state-changing action, who did it and what changed, kept for accountability rather than debugging. | Audit log |
| Blocker | The named reason a deployment is not progressing, such as capacity, image-pull or readiness. | Deployment states |
| Build | One attempt to produce an image from a service's Git source at one commit, run as a job inside the target cluster. | Builds |
| Builder | How a Git service's build turns its repository into an image: dockerfile, railpack, or auto to let each build decide. | Builds |
| Canvas metrics | The few numbers a service's card on the canvas shows for its kind, read over the trailing 30 minutes. | Logs and metrics |
| Change set | One person's staged edits to one environment, reviewed as a diff and applied together. | Change sets and approvals |
| Cloudflare connection | An organization's sealed Cloudflare API token, used to manage a domain's DNS records and issue DNS-01 certificates. | Domains |
| CloudNativePG | The Kubernetes operator that runs every Postgres database service as a replicated cluster with health-checked failover and backups. | Databases |
| Cluster | A K3s cluster enrolled with the control plane and running one agent. | Connect a cluster |
| Compose import | Turning a repository's Docker Compose file into services, with hostnames and credentials rewritten to references. NebulaCtrl never runs the Compose file itself. | Import from Compose |
| Control plane | The central service that stores the desired state and sends it to the agents. It serves the API and the console. | How NebulaCtrl works |
| Database connection | A service variable named for a database, such as DATABASE_URL_PG_APP, whose value references that database's connection URL. | Databases |
| Database service | A service created from a database template: PostgreSQL, Valkey, MySQL or MongoDB. | Projects and environments |
| Dependency | An edge from one service to another, which exists exactly when the first references the second or is linked to it. You never draw one by hand. | Deployments |
| Deploy after | A service's explicit list of services and databases its deployments wait for. | Deploy order |
| Deploy freeze | A recurring weekly window during which production deployments are refused. Rollbacks stay allowed. | Approvals and freezes |
| Deployment | One attempt to make a release active in an environment, tracked through a state machine to health. | Deployments |
| Desired state | The full set of releases, processes and domains the control plane wants running in a cluster, at a given revision. | How NebulaCtrl works |
| Domain | A hostname routed to one service and process through a cluster's ingress, or through an edge cluster. | Networking |
| Edge cluster | A publicly reachable cluster that serves a domain whose service runs on another cluster of the same organization. | Networking |
| Environment | A deployment target within a project, bound to one cluster, with its own namespace, variables and domains. | Projects and environments |
| External resource | A dependency outside the cluster, such as a database or cache, whose connection variables are linked into services. | Variables |
| File mount | One of a service's variables mounted as a read-only file at an absolute path. | Release commands and files |
| Git connection | An organization's authenticated link to GitHub, Forgejo or GitLab, used to list and clone repositories and receive webhooks. | Git providers and registries |
| Master key | The key in the control plane's .env file that seals every stored secret. | Secrets |
| Mesh | The organization's own WireGuard network that every node of every cluster joins. | Networking |
| Mesh grant | An admin's permission for every workload of one environment to reach one process of a service in another environment. | Networking |
| Mesh peer | One machine admitted to the mesh by one install grant, with an address and key that are never reused. | Networking |
| Node | A single machine inside a cluster. | Connect a cluster |
| Notification | A message to a member about an event they need to see, shown in their inbox and optionally sent to Slack or PagerDuty. | Notifications |
| Object store | An organization's S3-compatible bucket and credential that volume backups and database dumps are written to. | Volumes |
| Organization | The top-level tenant. Every project, cluster, member and API token belongs to one. | Projects and environments |
| Pod | A running instance of a process, as scheduled by Kubernetes. It appears in the runtime, logs and metrics views. | Processes |
| Preview environment | A short-lived environment cloned from a base environment for one same-repository pull request. | Preview environments |
| Process | A named way of running a service's image, such as an HTTP process, a worker or a cron job. | Processes |
| Project | A named grouping of services that ship together. A project holds environments. | Projects and environments |
| Project config | A nebula.toml at the root of a project's config repository that declares its services and databases and how they connect. | Project config |
| Project detection | The read-only probe a build runs over a repository to decide whether Railpack can build it. | Build detection |
| Promotion | Creating a release in another environment from an existing release's image. | Rollbacks and promotions |
| Protected environment | An environment marked as production. Changes to it need an approval. | Change sets and approvals |
| Public gateway | A node with a public IPv4 address that joins a cluster only to be its ingress on ports 80 and 443. | Networking |
| Railpack | The build engine that produces an image from a repository's project files, with no Dockerfile. | Build without a Dockerfile |
| Reader | A replica of a Postgres database that streams from the writer and serves reads only. | Databases |
| Recommended cluster | The connected cluster a new or unbound environment runs on by default. | Projects and environments |
| Reference | A variable value of the form ${{ SERVICE.KEY }} that resolves, when a release is frozen, to another service's variable. | Variable expressions |
| Release | An immutable image digest plus a frozen configuration revision, numbered per service per environment. | Deployments |
| Release command | A one-off command that runs with the new release's image before any process starts, typically a database migration. | Release commands and files |
| Repository config | A nebula.toml in a service's build context that configures the service from Git. | Configure from nebula.toml |
| Restore | Extracting an archive back onto a volume, which always wipes the volume's current contents first. | Volumes |
| Revision | The increasing version number of an environment's desired state, which the agent uses to ignore stale updates. | How NebulaCtrl works |
| Role | What a member or API token may do: owner, admin, deployer or viewer. | Projects and environments |
| Rollback | A deployment that makes a previously retired release active again. | Rollbacks and promotions |
| Service | A deployable unit within a project: an image plus one or more processes, deployed per environment. | Projects and environments |
| Source | How a service's image comes to exist: image, git, public-git or proxy. | Projects and environments |
| Tailnet device | The device the Tailscale operator puts on your tailnet for one tailnet domain. | Tailscale |
| Team | A named group of members that owns projects, set by hand or provisioned through SCIM. | Members and teams |
| Template | A YAML file describing a set of services, plus the inputs asked at install time. | Templates |
| Trigger-only | An image source with a push trigger, so a push creates a release once the matching image appears in the registry. | Deploy an image |
| Updater | The host service, nebula-updater, that runs the installer when you update the control plane from the console. | Upgrade |
| Variable | A key and value on a project, an environment or a service, optionally sealed as a secret. | Variables |
| Volume | Persistent storage attached to a process. A release that touches one needs a downtime acknowledgement. | Volumes |
| Volume backup | One copy of a volume's data in an object store: an archive, or for a database a logical dump. | Volumes |
| Writer | The one primary instance of a Postgres database, through which every write goes. | Databases |
Networking
How traffic moves in NebulaCtrl. Internal service hostnames, environment isolation, domains and certificates, Tailscale exposure, edge clusters and the WireGuard mesh.
Deploy from Git
Add a Git repository to a project, build it in your cluster on every push to an environment's branch, and deploy it by hand when you need to.