Deploy by framework

Go

Build and deploy a Go HTTP server with a managed container and optional public CDN assets.

Nitroship detects Go from go.mod. The managed preset downloads modules and builds a static server binary. Dynamic pages and APIs run on compute; an optional public/ folder is published to the CDN.

Deploy

Install the CLI

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

Already installed? Skip ahead. Full options, PATH setup, and updates: Install the CLI.

Choose a compute region; there is no default. Select Go explicitly in the deployment root:

nitroship.json
{
  "build": {"framework": "go"},
  "compute": {"regions": ["kr-icn"]}
}
ntro apps create my-go-app
ntro deploy . --prod

This preset requires the hosted builder. Remove --local from your deploy command. After deploying, open a server route and, if present, an asset URL at the address printed by the CLI.

Build and entrypoint

Commit go.mod and go.sum. The toolchain version comes from the go directive in go.mod, with .tool-versions as a fallback. The generated build selects a pinned supported toolchain/base version nearest the declaration, or a stable default when no version is declared.

The preset prefers a package main at the deployment root. Otherwise, it accepts exactly one main package under cmd/*. A library-only module or several possible cmd servers cannot be chosen automatically. Deploy the server's project root where possible, or use your own Dockerfile for custom selection.

The managed build produces a static binary. Projects requiring CGO, native shared libraries, or additional build tooling should use a custom Dockerfile.

Listen on the managed port

Your application must bind 0.0.0.0:$PORT itself. The preset cannot rewrite an arbitrary Go server's listening address. Use 3000 when PORT is unset; do not hard-code another port or bind only to localhost.

port := os.Getenv("PORT")
if port == "" {
    port = "3000"
}
log.Fatal(http.ListenAndServe("0.0.0.0:"+port, handler))

Use your application's existing handler in place of handler, with net/http, os, and log imported.

Static assets

When public/ exists, the generated image includes it at /app/public and stages public files under /nitroship/static. The builder automatically extracts those files to the CDN root before starting the server. public/logo.svg becomes /logo.svg. Server source, including .go files, must not be published.

Without public/, there is no static CDN output; all requests go to the Go server on compute. Assets embedded in the binary are not automatically extracted to the CDN. Use a public folder or your own Dockerfile if you want a different static layout.

Environment and runtime limits

Set secrets and application/database settings through Environment variables. DATABASE_URL is only a convention: your application must read it. Use an external database for durable data.

Generated images run as a non-root user. The instance filesystem is ephemeral; use /tmp for temporary writes only. Store uploads in S3 or other object storage, not in the image or public/.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run your project's migration command in CI or locally against the external database, and run workers separately. Use Cron jobs for scheduled HTTP work rather than an in-process scheduler.

Framework selection and Dockerfile escape hatch

build.framework: "go" selects Go explicitly and overrides an automatically discovered Dockerfile. It cannot coexist with build.dockerfile.

Without an explicit framework, Nitroship detects the build as described in How Nitroship chooses a build. For CGO, multiple binaries, system libraries, or custom build steps, remove build.framework and use your own Dockerfile.

On this page