Skip to main content
A Copper application deploys as a single binary, with templates, static assets, and migrations embedded at build time.

​
Building

To compile your application for production, run the build command:
This regenerates wire code, embeds your frontend’s built assets, and compiles every target under cmd/ into build/:
If your application has a web/ frontend, you should run its production build first, since copper build embeds the build output but does not run the frontend build itself:
You may use the --only flag to build specific targets:

​
Running in Production

Run migrations first, then start the app with your production config:
Copper shuts down gracefully on SIGINT and SIGTERM: in-flight requests finish, background goroutines are waited on, and cleanup hooks run, all within a 30-second limit. You should point your process manager’s stop signal at SIGTERM and allow at least that long.

​
Production Configuration

You should keep config/prod.toml free of secrets. Since config files are templates, you may pull secrets from the environment or a secrets manager at startup:
config/prod.toml
JSON logs with a level filter play well with log aggregators. To learn more, see Configuration and Logging.

​
Docker

Copper apps containerize well, since the whole application is a single binary plus a config directory. To learn how to write a multi-stage Dockerfile with proper layer caching, see Docker.

​
One-Off Overrides

You may override any config value at the command line without editing files: