Go on Falix

The Go application takes the compiled route: it runs a prebuilt binary and never touches a compiler on startup. When you press Start, Falix runs ./app in your server folder — that's it. So the whole task of hosting Go here is getting a Linux binary named app onto the server. There are two clean ways to do that.

The one rule: a binary named app

Falix runs the file named by the Executable variable, which is fixed to app and isn't user-editable — so renaming the binary to something else isn't an option. Whatever you build has to be named exactly app and be a Linux/amd64 binary — the format the container runs. Nothing compiles on the server, which means your build happens somewhere else first.

To run a genuinely separate Go app — a second service, another bot — don't juggle binaries in one folder. Give it its own Instance: an isolated application, files, and startup on the same server, switched whenever you like.

Path A: build locally, upload the binary

On your own machine, cross-compile for the server's platform and name the output app:

GOOS=linux GOARCH=amd64 go build -o app

That produces a single self-contained app file — Go links everything into one binary, so there's no runtime or extra files to ship alongside it. Upload it into your server folder with the File Manager or over SFTP (the host, port, and username are on the SFTP page; the password is your Falix account password), then press Start. Rebuild and re-upload whenever your code changes.

Path B: build on deploy from Git

If you'd rather push source than upload binaries, connect your repository on the Git page and add a post-deploy command that builds the binary on the server after each pull:

go build -o app

Now a git push (or a manual Deploy) pulls your latest code, compiles it into a fresh app, and you just restart. This keeps your whole workflow to committing and pushing — no binaries to move by hand — which is the nicer path once your project has more than one file. See Build steps for how post-deploy commands work, and Deploy your code with Git for connecting the repository in the first place.

⚠️ Heads up: Nothing on the Go server rebuilds itself. A reinstall — or switching the server to a different application — can wipe your files, the app binary included, and it won't come back on its own. Keep it somewhere you can re-upload it, or use the Git build-on-deploy path (Path B) so a redeploy compiles a fresh one.

Serving web traffic

A Go web server must read the port from SERVER_PORT and listen on all interfaces. Using ":"+os.Getenv("SERVER_PORT") as the address does exactly that — the empty host means "bind everything", which is what makes your app reachable from outside. Here's a complete, minimal server using only the standard library:

package main

import (
    "fmt"
    "net/http"
    "os"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello from Go on Falix!")
    })

    addr := ":" + os.Getenv("SERVER_PORT")
    fmt.Println("Listening on", addr)
    http.ListenAndServe(addr, nil)
}

Hard-coding a port, or binding 127.0.0.1, is the classic reason a Go app runs but can't be reached — see Your first web app.

🎯 Good to know: A program that isn't a server — a worker or a one-shot job — doesn't need a port at all.

Managing dependencies

The Go application has a Packages page in the server menu. Open Packages, search for the module, and press Install — behind the scenes it runs go get, updates your go.mod (and go.sum) for you, and shows the job under Tasks. It's the easy way to add or update a dependency without editing go.mod by hand.

⚠️ Heads up: Since your code is compiled ahead of time, remember to rebuild (Path A or B) after changing dependencies so the new module is baked into app.

Verify it works

Press Start and watch the Console page. A healthy server prints your program's own output — with the sample above, a Listening on :NNNNN line — and then stays running. If you built a web server, open your server's public address from the Network page in a browser and you should see the response. If the console instead shows an error and the server stops, read it from the top: the first line is almost always the real cause, and the troubleshooting entries below cover the common ones.

When things go wrong

• ./app: not found or a permission error on start — there's no binary named app in the server folder, or you uploaded a Windows/Mac build. Rebuild with GOOS=linux GOARCH=amd64 go build -o app and upload that file.
• exec format error — the binary is for the wrong architecture. Same fix: build for linux/amd64.
• Starts, then stops with no error — a program whose main returns exits cleanly and the server shows as stopped. That's normal for a script; a web server stays up because it blocks on ListenAndServe. See My app won't start.
• Server runs but the page won't load — a port or bind-address problem: I can't reach my app.

Next steps

• Build your first web app
• Build steps and post-deploy commands
• Deploy your code with Git