Containerizing Hyperterse gives you reproducible, portable deployments. The build artifact is a static binary with no external dependencies, so your final image can be extremely small — even scratch works.
Multi-stage build
Build from source inside a container and produce a minimal final image. Source files stay in the build stage and never reach the deployed image.
This approach is ideal when your CI pipeline builds the container image directly from the repository.
Pre-built artifact
If your pipeline already produces the dist/ directory (for example, as a CI artifact), skip the build stage and copy the output directly:
Scratch image
The Hyperterse binary is statically compiled. You can deploy it on a scratch base image with no OS layer at all:
This produces the smallest possible image — just the binary and the manifest.
Scratch images have no shell, no package manager, and no debugging tools. Use
them for production deployments where you have external observability in
place. For troubleshooting, use the Alpine-based image.
Docker Compose
Run Hyperterse alongside your database for local development or simple deployments:
Best practices
- Run as a non-root user. All examples above use a dedicated
hyperterse user with UID 1001.
- Use
env_file or secrets for credentials. Never bake connection strings into the image.
- Use health checks. Hyperterse exposes
/heartbeat — configure Docker’s HEALTHCHECK or your orchestrator’s probes to use it.
- Pin your base image. Use specific tags like
alpine:3.19, not alpine:latest.