Core concepts

Every page in these docs uses the same vocabulary. This page defines it, using the names the product actually uses. Read it once and the rest of the documentation will read as one system rather than a list of screens.

The model

Organization
├── Members & roles
├── Resources            registries · S3 destinations · DNS providers · certificate · SSH keys
│                        secrets providers · notification channels
└── Projects
    └── Environments     shared variables per environment
        └── Services     Application · Database · Docker Compose
            └── Deployments
                └── Domains  (routing + TLS)

Organization

The organization is the top-level tenant. It owns every project, every resource and every member, and it is the boundary for permissions and billing. A self-hosted installation typically has one organization; Cloud accounts can have more than one depending on the plan.

Everything is scoped to an organization: a project belongs to exactly one organization, and its services inherit that scope.

→ Permissions · Multi-tenancy

Member

A member is a person with a role inside an organization. Roles decide what a member can see and do — deploying, editing resources, or managing the organization itself. Members authenticate with an account and are the subject of authentication and API keys.

Project

A project groups related services that are deployed and managed together, for example "Storefront" or "Internal tools". It is an organizational boundary, not a runtime one: it does not host containers itself, it holds the services and the environments they run in.

Projects are where shared settings live, and they are the unit you navigate from in the dashboard.

Environment

An environment is a named deployment context inside a project — typically production and staging, but the name is yours. Each environment has its own set of services and its own shared variables, so the same project can target different databases, credentials and domains per environment without duplicating configuration.

Variable resolution flows from broad to specific: project → environment → service, where a service can reference values from the levels above it. See Environment variables.

Service

A service is a deployable unit inside a project and environment. Notploy has three kinds:

All three share the same operational surface: environment variables, monitoring, logs, deployments, domains and advanced settings. That consistency is deliberate — learn it once, apply it everywhere.

Deployment

A deployment is one immutable attempt to build and release a service. It has a status (queued, building, running, error, …), build and runtime logs, and it produces a specific image and container. Every deploy creates a new record; you can inspect the history, cancel queued deployments, and roll back to a previous one.

The deployment is the object that answers "what happened?" when a release fails.

Server

A server is an execution target — a machine where Notploy builds or runs workloads. Notploy distinguishes the local server (where the control plane is installed), deployment servers and build servers, and Swarm nodes. The deployment engine is identical; only the destination differs.

→ Servers · Deployment options

Domain

A domain binds a hostname to a service's container port and, when enabled, terminates TLS. Domains are how a service becomes reachable from the internet. They are backed by Traefik routing rules and can be auto-generated for quick tests.

→ Domains · Certificates

Resource

A resource is a shared infrastructure object an organization creates once and reuses across services. Resources are not workloads — they are configuration and credentials that services consume:

Status and availability

Throughout the documentation, features are marked so you never mistake a plan for a capability:

Related

• Ecosystem — how these concepts interact in practice.
• Glossary — a compact dictionary of terms.
• Editions & scope — how concepts differ across editions.