Projects and environments

Projects organise related services inside a workspace. Environments organise a project's runtime resources and help separate production from development or staging.

Create a projectCopy Anchor Link

From the workspace's project view, create a project with a name, optional description, and colour. Openstead creates a Production environment automatically.

A project is an organisational container, not a compute instance. Its services have their own plans and deployment history.

Find projects and servicesCopy Anchor Link

The workspace Overview shows a card for each project, with its name, description, and a summary of its services' status. Select a project to open it. Services that do not belong to a project appear in the Ungrouped services table below the project cards.

Inside a project, each environment has its own section and service table. Select a service name to open its details, or use an environment's New service button to create a service in that project and environment. Environment groups scoped to an environment are linked below its service table.

Status summaries follow the same health checks used elsewhere in the console; an old successful deployment does not make an unavailable service appear live. Use a service's environment-variable settings to manage shared variables and database connection references.

Add environmentsCopy Anchor Link

Create a Staging environment when you need to test code with separate configuration or data. A workspace includes up to two environments per project without qualifying paid services, or twenty with a qualifying active paid service.

An example layout:

Storefront project
  Production
    storefront-web
    storefront-worker
    storefront-db
  Staging
    staging-web
    staging-worker
    staging-db

The staging database is a separate service. Adding an environment does not clone production data automatically.

Private networking and referencesCopy Anchor Link

Applications and managed databases need to be in the same environment for private connection references. Choose the project and environment when creating each service.

If you move a service to a different environment, review its database references and linked environment groups. A reference to a source in the old environment becomes invalid. Prepare the destination dependencies before deploying the moved application.

See Private networking for network scope and Database connections for reference behaviour.

Protect an environmentCopy Anchor Link

Owners and admins can mark an environment as protected. Protected environments restrict changes to owners and admins, including operations on their services and related configuration. Use this for production resources when developers should have less direct write access.

Protection follows shared variables, database connection references, and preview copies. A service outside the protected environment that inherits this access keeps its owner/admin restriction after a link is removed. Running and retained deployments can still contain those credentials, so unlinking, moving the service, or deploying again does not automatically lower its access requirements. Owners and admins can continue managing it.

Environment protection is a role boundary. It is not an application test, a deployment-approval workflow, or a substitute for safe database migrations.

Share configuration carefullyCopy Anchor Link

Environment groups let you reuse configuration across linked services. Scope a group to an environment when those values should not cross into another environment, and keep production credentials out of staging groups.

Service-level variables and connection references still need to be consistent. A connected-database variable cannot also be defined with the same key in an ordinary variable or linked group. See Environment variables.

Rename and removeCopy Anchor Link

Renaming a project or environment updates its label; confirm any scripts that locate resources by name still select the intended item. Prefer resource IDs in API automation.

Move or delete services before deleting their environment or project. Linked environment groups also need to be moved or removed. These guards help prevent accidental deletion of containers that still own resources.