The most reliable way to install Go on a Linux VPS is to choose between the VPS distribution package and the official Go archive. Use apt or Snap when the distribution’s update and integration policy is more important than selecting an upstream release. Use the official archive when you need a particular Go version, the same layout across different distributions, or a predictable toolchain for deployments.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Whichever method you choose, installation is not complete until the correct Go directory and your Go-installed binaries are on PATH, the profile has been reloaded, and go version reports the intended release and Linux architecture.
As an Amazon Associate I earn from qualifying purchases.
Choose an installation method first
There is no universal winner. The right method depends on how tightly you need to control the toolchain and who will maintain the VPS.
| Method | Best for | Version control | Update and rollback considerations | Important limitation |
|---|---|---|---|---|
Distribution package with apt |
Ubuntu servers where tested distribution integration and normal system updates matter most | Normally follows the distribution’s packaged release; Ubuntu documents requesting a versioned package where available | Managed through the distribution package system; package availability and release cadence are distribution-specific | The repository may not offer the upstream release you need |
| Snap | Ubuntu installations that already use Snap and need a selectable Go release line | Snap channels can select a specific release line | Managed by Snap and its channel policy | Requires Snap to be available and may not match a minimal VPS image |
| Official Go archive | Exact release pinning, distribution-independent layouts, and controlled build environments | You select the archive and architecture explicitly | Replacing /usr/local/go with a chosen archive gives a straightforward manual rollback |
You must manage upgrades, removal of old files, and profile configuration yourself |
| Build from source | Toolchain contributors, unusual targets, or a controlled source-build pipeline | Controlled by the source revision and build process | Requires maintaining bootstrap and build dependencies | More complex than installing precompiled binaries; most users do not need it |
Do not mix methods casually. Installing a package and an archive at the same time can leave more than one go executable on the server, making the selected version depend on PATH order. Pick one primary installation for each account or document the full path deliberately when several versions are required.
Check the VPS before installing
Identify the operating system
On an SSH session, inspect the kernel and distribution information:
uname -s
cat /etc/os-releaseThe first command should identify Linux. The release file tells you whether the server is Ubuntu or another distribution and gives the release information needed when evaluating package availability.
Identify the CPU architecture
Run:
uname -mSelect an archive whose architecture suffix matches the VPS. The Go project lists instruction-set families including amd64, 386, arm64, and arm. The value printed by uname -m and the exact suffix shown on the Go downloads page must agree; do not assume that an archive built for one ARM variant is interchangeable with every other ARM system.
Record the intended version
For a production server, record the release selected for the application or deployment pipeline. The archive procedure below intentionally uses the filename shown on the current Go downloads page rather than hard-coding an old release. That keeps the installation reproducible without implying that a particular version is current forever.
Install Go from the official archive
The archive method gives you the clearest control over the exact release and installation location. The standard layout is /usr/local/go, with the compiler and standard tools in /usr/local/go/bin.
1. Select the current Linux archive
Open the official Go downloads page from a browser or use the release information already approved for your deployment. Choose the Linux archive for the architecture discovered above. The filename follows the pattern go<version>.linux-<arch>.tar.gz. Keep the exact filename; it is used in the download and extraction commands.
2. Download the archive over HTTPS
Use a downloader that is installed on the VPS. The Ubuntu guide illustrates this pattern:
wget https://go.dev/dl/go<version>.linux-amd64.tar.gzReplace the version and architecture portions with the exact values selected from the downloads page. If wget is unavailable, an equivalent HTTPS download with curl is suitable. Save the archive in a working directory and record the selected release in your change notes.
3. Remove any previous archive installation
Before extracting, remove the old Go tree:
sudo rm -rf /usr/local/goThe Go project explicitly warns: “Do not untar the archive into an existing /usr/local/go tree. This is known to produce broken Go installations.” An extraction over an old tree can leave files from two releases mixed together, so do not skip this step during an upgrade.
4. Extract into /usr/local
Run the extraction command from the directory containing the downloaded archive:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo tar -C /usr/local -xzf go<version>.linux-<arch>.tar.gzUse the archive’s exact architecture suffix. After extraction, the directory should be /usr/local/go, not a nested path such as /usr/local/go/go.
5. Add the Go distribution to PATH
For a system-wide installation, create a profile fragment such as /etc/profile.d/go.sh containing:
export PATH="$PATH:/usr/local/go/bin"Writing this file requires administrative privileges. If only one administrator account needs Go, the same export can be placed in that account’s ~/.profile instead. The first entry exposes the compiler and the tools shipped with the Go distribution; it does not automatically expose binaries installed by go install.
6. Add binaries installed by go install
Go-installed command-line programs normally go into the user’s Go workspace binary directory. Add it separately:
Rank #3
export PATH="$PATH:$(go env GOPATH)/bin"Place this line in the same profile after the Go distribution path, or use the concrete directory represented by $(go env GOPATH)/bin. Keep the two purposes distinct: /usr/local/go/bin contains the Go distribution’s own tools, while $HOME/go/bin (the usual default represented by $(go env GOPATH)/bin) contains executables installed for that user.
7. Reload the profile and verify
A profile edit affects future shells, not every shell that is already open. Reload the relevant file:
source ~/.profileIf the system-wide file was changed, start a new SSH session when necessary so the login environment reads it. Then run:
command -v go
go versioncommand -v go should point to the installation you intended, normally /usr/local/go/bin/go for the archive method. go version should print the selected Go release and the Linux platform architecture. The Go project’s verification instruction is to confirm that the command prints the installed version.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallInstall Go on Ubuntu with apt
Ubuntu documents Go as a Debian package. This is the simplest route when the repository’s tested integration and update process are more important than choosing an upstream release independently.
- Refresh package metadata:
sudo apt update - Install Go:
sudo apt install golang-go - Verify the installation:
go version
The package manager places files according to Ubuntu’s packaging policy and handles updates through the normal distribution workflow. The exact Go release supplied depends on the Ubuntu release and enabled repositories, so inspect the resulting go version rather than assuming it matches the newest upstream release.
Requesting a versioned Ubuntu package
Ubuntu’s developer documentation also describes versioned packages such as golang-1.21 and golang-1.23. Availability depends on the Ubuntu release and repositories configured on the VPS. When separate applications require different toolchains, test the versioned installations through their documented full paths under directories such as:
/usr/lib/go-<version>/bin/Use the exact path for the installed package rather than relying on whichever binary happens to appear first on PATH.
Install Go on Ubuntu with Snap
Snap is another Ubuntu-supported route:
sudo snap install go --classic
go versionSnap channels can select a specific release line. This is useful when the required Go release is available through Snap but not through the VPS’s normal Debian package repositories. Confirm that Snap is installed and usable on the image before choosing this method, particularly on minimal server images.
As with the other methods, run command -v go and go version after installation. If another Go installation is already present, inspect the path and remove the ambiguity rather than assuming the newly installed Snap executable is selected.
Configure shells, users, and service accounts correctly
Interactive SSH users
Interactive login shells commonly read profile files, but a profile change is not retroactive. Source the file or open a new SSH session before testing. If one user installed tools into $HOME/go/bin, another user will not see those executables unless that second user has its own installation or an explicitly shared path.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Non-interactive deployment commands
Automation may start a non-login shell and skip ~/.profile. Put the required export in the deployment environment or invoke the intended executable by absolute path. For example, a build script can call /usr/local/go/bin/go when the archive installation is the approved toolchain. This removes dependence on the order of inherited environment variables.
System services
Do not assume an interactive administrator’s profile is loaded for a service. Configure PATH explicitly in the service manager or deployment unit, and use an absolute Go path when operational predictability matters. Test the service in the same init and deployment environment used in production; service-manager behavior depends on the VPS’s init configuration.
Verify the installation methodically
Use this sequence after every fresh installation or upgrade:
- Open a new SSH session or reload the profile that contains the exports.
- Run
command -v goand compare the result with the path you intended. - Run
go versionand confirm both the expected release and Linux architecture are printed. - Run
go env GOPATHif you need to identify the user workspace whosebindirectory should be onPATH. - Install or invoke a project-specific tool only after the compiler path is unambiguous.
If the command reports a different release than expected, the installation may be correct but shadowed by another executable earlier in PATH. Inspect the path order and either remove the unintended installation or call the desired binary explicitly.
Free tools Windows power users keep installed
One-click scans. No signup required.
Troubleshoot common failures
go: command not found
- Reload the profile or open a new SSH session.
- Print the current path with
echo "$PATH"and check for/usr/local/go/binwhen using the archive method. - Run
command -v goafter reloading. - If the archive was extracted elsewhere, correct the profile to the actual installation directory or extract it again into
/usr/local.
The wrong Go version appears
- Use
command -v goto identify the selected executable. - Look for an older package, Snap installation, or manually installed tree earlier in
PATH. - For versioned Ubuntu packages, call the full path under
/usr/lib/go-<version>/bin/in the build or deployment script. - Do not solve the problem by repeatedly appending paths without documenting the intended order; that makes later upgrades harder to diagnose.
The archive installation behaves inconsistently
If an upgrade was extracted over an existing /usr/local/go, remove that directory completely and extract a fresh archive. The official warning exists because a mixed tree can produce a broken installation even when go version appears to run.
Tools installed with go install are missing
Adding only /usr/local/go/bin exposes the distribution tools, not user-installed executables. Add $(go env GOPATH)/bin to the same user’s profile and reload it. Check that the tool was installed for the account running the command; another service account has a different home directory and usually a different workspace.
The archive will not run on the VPS
Recheck uname -m and compare it with the archive suffix. The Go source documentation lists amd64, 386, arm64, and arm targets, but the matching binary still has to correspond to the actual VPS architecture. If the architecture is unsupported by the chosen package source, use an available distribution package or an appropriate build process.
Run multiple Go versions deliberately
Side-by-side versions are useful when separate applications have incompatible toolchain requirements. Ubuntu documents installing versioned packages such as golang-1.21 and golang-1.23, then testing each through its full path under /usr/lib/go-<version>/bin/.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Keep the selected compiler explicit in build scripts, CI jobs, and deployment units. A global PATH change can silently switch an application to another release during a package upgrade. If you use archive installations for side-by-side releases, apply the same principle: keep each approved tree identifiable and invoke the selected binary explicitly rather than relying on whichever directory was appended last.
When building Go from source makes sense
The Go project says most users should install precompiled binary packages. A source build is appropriate for toolchain contributors, unusual targets, or a controlled pipeline that must build the compiler itself.
Source builds require a bootstrap toolchain. The source instructions describe the required bootstrap process and note that a C compiler is optional unless cgo support is required. This path therefore introduces more dependency and maintenance work than an archive, Debian package, or Snap installation. Use it only when the reason for building from source is stronger than the operational simplicity of a precompiled distribution.
Practical decision guide
Choose apt when
- The VPS is Ubuntu and its packaged Go release satisfies the application.
- You want updates handled through the distribution’s normal security and maintenance process.
- Other administrators expect software to be managed by the system package manager.
Choose Snap when
- Snap is already part of the Ubuntu image.
- You need a release line that is available through Snap channels.
- The team is comfortable maintaining software through Snap rather than Debian packages.
Choose the official archive when
- The application requires a specific upstream release.
- You deploy the same toolchain layout across different Linux distributions.
- You can document manual upgrades, profile changes, and rollback procedures.
Choose a source build when
- You are contributing to the Go toolchain.
- You need an unusual target or a controlled compiler-build pipeline.
- You can provide and maintain the bootstrap environment and any cgo compiler dependency.
Final installation checklist
- The operating system and architecture were identified with
unameand the distribution release file. - The installation method matches the required release-control and maintenance policy.
- An archive installation removed the old
/usr/local/gotree before extraction. /usr/local/go/binis onPATHfor the compiler and standard tools.$(go env GOPATH)/binis on the relevant user’sPATHfor tools installed withgo install.- The profile was reloaded or a new SSH session was opened.
command -v gopoints to the intended executable.go versionprints the expected release and Linux architecture.- Build scripts and service units use an explicit compiler path when more than one Go version exists.
For most Ubuntu VPS users, start with apt if its packaged release is acceptable. Select the official archive when version pinning or a consistent cross-distribution layout matters, and treat Snap or a source build as deliberate alternatives rather than accidental mixtures.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
