Skip to main content
A language runtime builds your repository without a Dockerfile. You pick the language and version, slipway generates the build, installs dependencies from your lockfile, and starts the service. A repository that has a Dockerfile is unaffected. A runtime applies only when you select one instead.

​
Available runtimes

runtime: docker means the opposite of these: build the Dockerfile committed in the repository.

​
Selecting a runtime

When you deploy a repository that has no slipway.yaml, no docker-compose.yml and no Dockerfile, slipway looks for a language marker and preselects the matching runtime.Confirm the runtime and version, optionally set a build command and a start command, then deploy.
If you omit runtimeVersion, slipway uses the default in the table above. When a default moves up, your next deploy builds on the new version. Pin the version to opt out of that. runtime cannot be combined with dockerfilePath or dockerTarget. A runtime generates its own Dockerfile, so there is nothing for those fields to point at.

​
Rebuilds

A runtime build is reused unless the commit, the runtime, the version or the build command changes.

​
Compiled runtimes

Go and Rust build in a separate stage and ship a small runtime image. If you set a custom buildCommand for them, it owns that stage and must place the output where the runtime image expects it: The default build commands already do this.

​
When to commit a Dockerfile instead

Use a Dockerfile when you need system packages, a private build step, a process manager, or a base image the runtimes do not offer. A Dockerfile can take over from a runtime at any time. Change the service’s source in the Blueprint editor, or set runtime: docker in the spec.

​
FAQ

Can different services in one project use different runtimes? Yes. A runtime is set per service. A Node frontend and a Go API can sit in the same project, from the same repository or different ones. Does a runtime service get a build cache? Yes. Dependency installation is cached the same way a Dockerfile build is. Does the build see my environment variables? Yes. Every value in the service’s env is available to the dependency install and the build command, so a framework that inlines values at build time, such as Next.js with NEXT_PUBLIC_*, picks them up. Changing a value and redeploying rebuilds those steps. See how values reach the build.