Skip to content

Go deploys

Deploy Go applications to your own server

Ship a Go service to a server you control without stitching together a build script, a process manager, and a reverse proxy. Phelix owns the path from source to serving traffic, in one CLI.

Released Phelix hosts: Linux and macOS. Builds Go and Rust with your host toolchain.

From source to a versioned binary

One command compiles your Go module into an immutable, numbered build.

Phelix builds native Go binaries directly on the host using the installed Go toolchain, or the latest (Go 1.27.1) when none is present, with no container step required. Every build is a numbered version paired with a build report and an encrypted environment snapshot, so you always know exactly what is running and can return to it later.

The full command set, the interactive wizard, and the lifecycle verbs live in build and lifecycle. For the model behind it all, start with the overview.

phelix · build
phelix build
built api v3 go1.27 linux/amd64
report cache 91% regressions 0
env encrypted snapshot saved

Deploy the exact commit

Push to deploy, or run the deploy yourself. Either way, the binary that serves traffic is the one you built.

Wire an HMAC-authenticated Git webhook and Phelix deploys the exact pushed commit, with durable jobs and restart recovery, as described in Git webhook deploys. Or run the deploy by hand and pick the strategy that fits the service.

Classic, blue-green, rolling, and canary are all covered in deployment strategies. Classic is a stop then start and can drop traffic briefly; the proxy-based strategies do not.

phelix · deploy
phelix deploy api --blue-green
starting candidate v3 on :8081
health http ok tcp ok pid ok
proxy cutover :8080 to v3
active v3, drained v2

Health-gated cutover, and a way back

Traffic moves to a new version only after it passes its checks, and every version stays one command from rollback.

On proxy-based deploys, Phelix starts the new version, health-checks it, and switches the host-local HTTP proxy only when it is ready. If a deploy goes wrong, roll back to a retained version through the same topology. The mechanics are in zero-downtime deployment for Go and the versions and rollback docs.

Health checks reduce risk; they do not prove that every behavior of your application is correct. Treat them as a gate, not a guarantee.

Where it runs

Phelix operates applications on infrastructure you already have.

Released Phelix hosts run on Linux and macOS, and the whole tool is a single binary with no Kubernetes to operate. Phelix does not provision the server: you bring the machine, the network, and TLS, and Phelix takes over at build, deploy, health, and rollback.

Environment values are encrypted at rest with AES-256-GCM using a local key. That is encrypted local storage, not a remote secrets vault; see environment and security for the model.

One binary between git push and production.

Install the CLI, verify the host, and follow the quick start to build your first application.

Read the docs