How Teral is organized
Workspaces, projects, apps, environments, deployments and instances.
Workspace
└── Project
└── App
├── Environment: production
│ └── Deployments → Instances
└── Environment: preview
└── Deployments → InstancesWorkspace
Your account's top level. Billing, team members, API keys, limits and audit logs belong to a workspace. Nothing is shared between workspaces. See Workspaces.
Project
A group of apps that belong together, usually one product or one repository. The project's slug is part of every URL its apps get.
App
One service you deploy, such as an API or a website. An app has one source: a GitHub repository or a container image. It has its own settings, variables, domains, gateway policies and deployment history.
A project can have several apps, for example an API and a worker built from the same monorepo with different root directories.
Environment
Every app has two environments: production and preview. Most settings, all variables and every custom domain are set per environment, so preview can use a test database while production uses the real one. See Environments.
Deployment
One version of an app in one environment, built from one commit or image. Deployments never change after they're created. To change code, variables or settings, you create a new deployment. That's what makes rollbacks safe.
Instance
One running copy of a deployment in one region. A deployment runs between the minimum and maximum number of instances you set per region. See Scaling and resources.