Skip to main content
A blueprint is a project’s service definition: which services exist, how each builds, and how they depend on each other. Underneath it is a slipway.yaml, and the Blueprint editor is a visual way to author one.

​
The editor

Open it from the create palette, with New or ⌘K then Blueprint, or from any service’s Blueprint button. Services are listed on the left. Selecting one edits everything about it on the right: source (a language runtime, a Dockerfile or an image), start command, ports, type, schedule, replicas, CPU and memory, and disks. A startup-order line above the list shows the composition at a glance. The YAML button switches to the raw file at any time, and both views edit the same thing. Pasting a docker-compose file there offers a one-click conversion.

​
Where the blueprint lives

A blueprint authored in the editor is stored by slipway and deploys with no file in the repository. Each service’s YAML dialog controls which source wins. Blueprints created in the editor default to Dashboard, so a later commit cannot silently change your configuration. Exporting the YAML and committing it is how you move to file-based config when you want it reviewed in pull requests. See Overview.

​
Dependencies

Each service’s Starts after control lists its siblings. Selected services must pass their readiness probes before this one starts, and deploy order follows. Cycles cannot be selected. References such as ${service.postgres.host} in environment values resolve automatically. Edit those under the project’s Variables & secrets.