Creating one
Your organization’s landing page is the Projects list. Select New, or press ⌘K (Ctrl+K on Windows and Linux), to open the create palette. It asks two things: where this goes, and what it is. The line at the top is the destination. It reads New project unless you opened the palette inside a project, in which case that project is already selected.
The service types then ask where the code comes from: a repository this workspace already
sees, a new one to connect, or a public image.
Everything is reachable from the keyboard. Arrow keys move, Enter selects, and
Backspace on an empty search goes back a step.
For a repository, pick it, keep the default branch, and select Deploy. The panel shows
which spec file the deploy reads. If the repo has more than one candidate, a picker lets you
choose and the project keeps deploying from the file you picked. You can set a per-service
spec path for monorepos, such as
apps/api/slipway.yaml.
Changing a project
Open its Settings tab: General for the name, composition and per-service options, plus Domains, Variables & secrets, Notifications and the Danger zone. You are offered a redeploy when a change affects what is running. Variables and secrets set here apply to the whole project and override organization values. See Secrets and variables.Labels
A project can carry one label — production, staging, development, or anything you write — with a dot color of your choosing. It shows next to the project’s name on the projects list and in its header, so which project is which is answerable at a glance. Set it under Settings → General; leave it empty for none. A custom label is saved to the project the moment you create it, so it stays in the dropdown as a reusable choice even after you switch to a preset. The trash icon on a saved label removes it from the dropdown — if the project currently carries that label it keeps it until you change it. The three presets are always available and can’t be removed.Cloning
Select Clone in a project’s header to create a new project with the same shape, services, variables and config, retargeting each service’s branch or tag as you go. Secret values are not copied. Re-enter them in the clone before its first deploy. Disks seed from the source’s default snapshot when one is set, so a clone starts with realistic data. See Disks.States
A project is always in exactly one status.degraded is soft: redeploying the failing service returns the project to healthy.
See Statuses and events.
Always-on
Services hold their pods around the clock rather than starting on the first request, and stay up until you tear the project down. Always-on is a plan capability checked at deploy time, not a per-project toggle. On the Free plan, wakeable web services sleep after five idle minutes instead. See Plans. Auto-deploy is separate and per service. A project created from a repository has it on; services added later default to off. See How deploys work.There is no cap on how many projects you can run. What bounds them is what they cost. An
always-on project bills around the clock at the sum of its services’ rates.
Settings → Usage shows the current burn rate and how long your balance lasts at it.
Service ids
Every service gets a stable id the first time it deploys:websvc-a1b2c3d4e5f6 for a web
service, worker-… for a worker, cj-… for a cron job. It is assigned once and never
changes, including when you rename the service or change its type, so a link you shared last
month keeps working.
Console URLs use the id. The API accepts either the id or the service name:
${service.<name>.<field>} resolves against. The id addresses a service
from outside; the name reaches it from inside.
Removing a service retires its id rather than deleting it, so its metrics, deployment history
and logs stay reachable. See Archived services.
Renaming a service
Open the service, go to Settings and use the pencil next to its name. Confirming rewrites the service’s spec and redeploys it under the new name. Its id, deployment history, metrics and settings (compute, subdomain, IP rules, alerts) carry across. The public hostname follows the name, so links to the old host stop working once the new deploy is live, and the old workload is removed at that point. The pencil is offered on single-service projects created from the console. A project with several services is renamed from its Blueprint, and the change applies on the next deploy. A service that follows a committedslipway.yaml is renamed by editing that file and pushing.
Talking between services
Every service in a project shares one private network and reaches a sibling by its bare name. Service names are therefore unique across the project. When you add a service from the console and the name is taken, slipway appends a number, so addingapi twice gives you api-2. A collision only a spec change could resolve fails the
deploy with an error naming both sides.
See Service to service for the reference syntax and every
resolvable field.
Public URLs
Every public service is served at a stable host:prefix: you set. Hostnames do not change across
redeploys. To serve under your own zone, see Custom domains.