> ## Documentation Index > Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt > Use this file to discover all available pages before exploring further. # Projects > Deploy several services together as one unit that shares a network and config. A project ties one or more services together so they deploy as a unit, share one set of variables and secrets, and reach each other by name. Every deployment belongs to a project. A project's services can come from anywhere: a repository, a prebuilt image, or a managed database. A single-repo project is the common case. Composing several is how a frontend, an API and a worker come up side by side. A project owns exactly one runtime. Its services, its config and its deployments live in one isolated space, and deploying the project deploys them there. Pull requests are the exception: each can spawn a temporary [preview](/previews/pr-previews) on its own URLs, archived when the PR closes. ## 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. | Type | What you get | | - | - | | Static site | A site built once and served from the CDN. No compute allocation. | | Web service | An HTTP service, public or internal. | | Cron job | A command on a schedule. | | Database | Postgres, [Redis](/data/redis), MySQL or ClickHouse, with a disk, password and backups prewired. | | Object storage | An S3-compatible [bucket](/data/object-storage). | | From the marketplace | A ready-made app from the [catalog](/projects/marketplace). | | Blueprint | A project defined by a [spec you write in the console](/projects/blueprints), with no repository. | | Empty project | A blank project to add services to later. | 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](/slipway-yaml/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](/data/disks). ## States A project is always in exactly one status. | Status | Meaning | | - | - | | `creating` | The row exists and nothing has deployed yet. | | `ready` | Configured, with no deploy in flight. | | `deploying` | One or more services are in flight. | | `healthy` | Every service is healthy. | | `degraded` | At least one service failed while others keep serving. | | `failed` | Everything failed. | | `sleeping` | Scaled to zero on idle. | | `resuming` | Waking. | | `tearing_down`, `torn_down` | Teardown in progress, then finished. The row stays for history. | `degraded` is soft: redeploying the failing service returns the project to `healthy`. See [Statuses and events](/reference/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](/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](/deploys/how-deploys-work#auto-deploy-on-push). > [!NOTE] > > 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: ``` /api/orgs/{slug}/projects/{projectId}/services/websvc-a1b2c3d4e5f6/restart /api/orgs/{slug}/projects/{projectId}/services/api/restart ``` The **name** is what everything inside the cluster uses: the DNS name a sibling reaches the service by, and what `${service..}` 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](/projects/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 committed `slipway.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 adding `api` 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](/networking/service-to-service) for the reference syntax and every resolvable field. ## Public URLs Every public service is served at a stable host: ``` https://. ``` The label is the service name, or a `prefix:` you set. Hostnames do not change across redeploys. To serve under your own zone, see [Custom domains](/networking/domains). ## Deploy latest **Deploy latest** re-resolves every tracked ref to its newest commit and redeploys. Before you confirm, it shows what each tracked ref would move to, and which variables and secrets have changed since the last deploy. Variables show old and new; secret values are write-only, so a rotation shows as rotated. ## Teardown Teardown supersedes every in-flight deploy and removes the project's runtime: every service, every URL and its namespace. The row and its log stay for history. You can also tear down a single service from its page, leaving siblings untouched. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.