Проекты и окружения

The object model is the same as Railway's:

workspace            billing, members, API tokens
└── project          a canvas: services, databases, volumes, domains
    └── environment  production, staging, pr-42 …
        └── service  a repository or an image
            └── deployment

Workspaces#

Signing in with GitHub creates a personal workspace with a small trial credit. Workspaces own the balance and the plan (Billing), the members and their roles (owner, admin, member) and API tokens. Create more workspaces from the workspace switcher or with workspaceCreate; those do not receive the trial credit.

Projects#

A project groups the services of one application. Everything inside a project shares a private network per environment and can reference each other's variables.

Project settings hold the name, description, the GitHub App installation used for private repositories and the PR deploys toggle (see below). Deleting a project removes its services, volumes and environments.

Environments#

Every project starts with production. An environment is a full copy of the service graph: the same services with their own settings, variables, domains, volumes and deployments. A service is created project-wide; its per-environment settings (ServiceInstance) are created with defaults when you first touch them.

skiffly environment                        # switch the linked environment
skiffly environment list
skiffly environment new staging --duplicate production

--duplicate copies variables and service settings from the source environment. In GraphQL that is environmentCreate(input: { projectId, name, sourceEnvironmentId }).

Per-environment branch override: a service tracks one branch by default; with serviceInstanceUpdate(input: { branch }) (or branch in config as code) you can point staging at develop while production stays on main.

Preview environments per pull request#

Turn on PR previews in project settings (projectUpdate(id, input: { prDeploys: true })). Then, for every pull request opened against a connected repository:

1. An environment named pr-<number> is created as a copy of production.
2. Services built from that repository follow the PR branch; other services (databases, workers from other repositories) deploy as in production.
3. Each push to the PR redeploys only the services from that repository.
4. Closing or merging the PR deletes the environment, its volumes included.

Pull requests from forks are ignored: they would run someone else's code with your secrets.

Members and roles#

Invite people from People in the workspace sidebar (workspaceInvite). Roles: owner (everything, including deleting the workspace), admin (billing, tokens, members), member (projects, services, deployments, logs, shell). Access is per workspace; there are no per-project permissions yet.

Audit log#

Every mutation that changes something is written to the workspace audit log (auditLog(workspaceId)): deploys, variable changes, domain changes, shell sessions, billing events. The dashboard shows it under Settings → Audit logs.