:::meta author=Docs-Team updated=2026-09-03 tags=service,wizard,create,deployment
:::
:::breadcrumb Docs > User Guide > Creating a Service
:::
:::reading-time
:::
Creating a service is a four-step wizard: Service → Network → Volumes → Confirm. It starts from the Create service button on a plan card (or the equivalent buttons in the services area) and ends with a service shell that is ready for its first deploy. This page documents every step, every field, and the validation rules you may meet along the way.
:::toc
:::
Before you start
The wizard needs a signed-in session. If you opened it as a guest, it shows a lock card with "Not authenticated" and a Login button that routes you to the sign-in page — your place in the wizard is preserved by the browser, so you can continue after authenticating. The wizard subtitle always shows the selected plan: Plan: name · platform · Storage quota MB.
:::steps
• Service
Enter the Service name — for example my-api. The name identifies the service across the dashboard, the shell, and share rules; the only rule is that it cannot be empty.
• Network
Select one of your private networks, or create a new one inline. The step requires at least one network before you can continue.
• Volumes
Optionally attach unused volumes or create new ones, within the plan's storage quota.
• Confirm
Review every choice on one card, jump back with the Edit buttons, and press Create.
:::
Step 2 — Network
Every service runs inside a private Docker network. The step lists your networks as radio cards; the selected one is highlighted, and the list loads with a spinner. If you have no networks yet, an info alert offers to create one.
The Or create network area has a single Network name field and a Create button. On success, the message "Network created and selected." appears and the new network is chosen automatically, so you can continue without extra clicks. Empty names are rejected with "Network name is required."
:::tip
Network names are only labels — you can create a network per environment (e.g. staging, production) and reorganize services later from the service settings. See [networks.md](networks.md).
:::
Step 3 — Volumes (optional)
Volumes are persistent storage that survives redeploys. This platform uses an exclusive attach model: a volume belongs to at most one service at a time, so only your unused volumes are listed. The step header explains it — "Attach volumes (exclusive to this service)" — and a quota alert keeps the arithmetic visible: Plan storage: X MB · Selected: Y MB · Remaining: Z MB, where the quota is the plan's storage in GB converted to MB.
Each volume row shows its name, a bind-path chip (e.g. /data), and its size in MB. Volumes that would push you over the quota are disabled and flagged with a red Exceeds quota chip. If you need storage, the Create volume form asks for:
| Field | Rule |
| --- | --- |
| Name | Required |
| Bind path | Must be absolute, e.g. /data |
| Size MB | Number, minimum 1, maximum the remaining quota |
The Create & select button attaches the new volume to the service immediately after creation. Validation messages are explicit — "Bind must be absolute path, e.g. /data" or "Not enough plan storage. Remaining for selection: N MB." — so mistakes are easy to fix.
[!NOTE] You can skip volumes entirely. A service without volumes still deploys and runs; you can attach storage later from the service settings, subject to the same quota.