slipway.yaml for. Pick one, answer a couple of questions, and it deploys, with no repository, no Dockerfile and no spec to author. It is in the sidebar, and under New → From the marketplace.
The gallery opens with a short featured shelf, and the full catalog can be searched or browsed by category and by type (standalone or app).
Entries come in two kinds, and the difference is where they can be installed.
Standalone
These deploy as their own project, or alongside what is already in one. You choose on the install screen.Apps
An app runs against a database, and comes up already connected to it.
Installing one puts it in the same project as the database, which is what lets it find it: services in a project share a private network and reach each other by name. slipway fills in the host, port, database, user and password, so there is no connection string to copy.
You can start from either end: browse the Marketplace and pick a database to attach to, or open a database’s Apps tab and install from there. Both land on the same install screen.
If you don’t have a database yet
The install screen offers to create one. Choose Create a database with it and you get a name, a version and a disk size to confirm; slipway then creates a new project holding both the database and the app, wired together. What you get is an ordinary managed database, identical to one made from New → Database, with its own credentials, external access toggle, backups and disk. It is a service you own from then on rather than something bundled inside the app. The whole install is one operation. Either the project, the database, the app and the generated password all exist, or none of them do.Standalone
Most apps can also run standalone with nothing pre-connected. The install screen offers Run standalone alongside the other two, and the app lands in a project of your choosing. Add connections from inside the app whenever you like.Every entry has a page
Selecting anything in the Marketplace opens its page rather than a form: what the software is, who makes it, its license and version, links to its own docs and source, and exactly which services deploying it will create. Most entries also carry a short overview and a Getting started walkthrough for the first minutes after it deploys: claiming the admin account, wiring the first integration, and where the generated credentials live. Install is on that page.The install screen
One page, in four parts.- Destination. A new project, which you name, or an existing one. For an app, you choose between attaching to a database you already run (picked from every eligible one in your organization, and its project is where the app lands), creating one with it, or running standalone where the app supports it.
- Configure. Whatever the template declares. Each input is either a value you choose or a value slipway generates.
- Compute. CPU and memory per service. Multi-service templates configure each one separately; the app and its database rarely want the same shape.
- Review. The running cost estimate and the Install button, which follow you down the page.
Generated credentials
You never see a blank field for a password. slipway creates it on the server and stores it as a project secret, so the value never passes through your browser. For apps with their own sign-in, such as pgAdmin, MinIO and Vaultwarden, the generated credentials appear on the service’s Connections card once it is running. The username is in plain text and the password is masked until an admin reveals it. To change one, edit the value on the project’s Variables & secrets tab and redeploy the service.After it deploys
A template leaves behind an ordinary project.- The spec is an ordinary stored
slipway.yaml. Open it in the Blueprint editor and change anything. - Resize services, add your own alongside, attach a custom domain, roll back a deploy.
- Secrets and variables live in the project like any other.
Pinned images
Every entry pins an exact image tag rather thanlatest, and that tag is the version shown on its page. Deploying the same template twice gives you the same software, and a rollback returns to something real.
Updating means editing the image tag in the spec and redeploying, so a new version never arrives on its own.
What the Marketplace can’t do
- It does not build from source. Every entry runs a prebuilt public image, so there is no repository behind one. To deploy your own code, connect a repository instead.
- It is not where managed databases live. Postgres, MySQL, Redis and ClickHouse have their own flow under New → Database, with credential management, external access and backups. An app install can create the one it needs, which is a convenience on the way to installing the app.