If you want to install conda Ubuntu Server safely, use Miniconda unless you specifically need the full Anaconda Distribution. Miniconda gives you conda, Python, and the minimum packages needed to create environments. That is usually the cleaner choice for a VPS because you can install only the data-science, machine-learning, or automation packages your project needs.
This guide uses a per-user installation. That keeps conda separate from Ubuntu’s system Python and reduces the chance of breaking operating-system tools that depend on distribution packages.
Key takeaways
- Choose Miniconda for most Ubuntu Server installations.
- Do not replace or modify Ubuntu’s system Python.
- Download installers from official Anaconda locations.
- Verify the installer hash before running it.
- Install into a user-owned directory such as
~/miniconda3. - Create a project environment instead of working in
base. - For related setup work, read the Virtarix guides to managing packages with apt, Linux command line tips, checking CPU usage on Linux, and VPS backups.
Miniconda or Anaconda?
Miniconda is the better default for servers. It is smaller, starts with fewer packages, and lets each project define its own environment. Anaconda Distribution includes many data-science packages up front, which can be convenient on a workstation but heavier than necessary on a VPS.
Use Miniconda when:
- You want a lean server install.
- You manage one environment per project.
- You need reproducible package lists.
- You want to avoid installing hundreds of packages you may not use.
Use the full Anaconda Distribution only when you specifically want its larger bundled package set and accept the disk space and maintenance tradeoff.
Step 1: install basic prerequisites
On a fresh Ubuntu Server, make sure you have common download and certificate tools:
sudo apt update
sudo apt install curl ca-certificates
Keep this separate from conda. Ubuntu packages support the operating system. Conda environments support your projects.
Step 2: download the miniconda installer
Download the current Linux installer from the official Anaconda repository:
curl -fsSL -o ~/miniconda.sh https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
If your server uses a different CPU architecture, choose the matching installer from the official Miniconda download page. Do not blindly use an x86_64 installer on ARM hardware.
Step 3: verify the installer hash
Before running the installer, compare its SHA-256 hash with the official value published by Anaconda:
sha256sum ~/miniconda.sh
If the hash does not match, stop and download the installer again from the official source. Do not run an installer with an unknown or mismatched checksum.
Step 4: install miniconda in batch mode
Run the installer into a user-owned directory:
bash ~/miniconda.sh -b -p "$HOME/miniconda3"
The -b option runs the installer without prompts, and -p sets the installation path. A home-directory install is easy to remove and does not require root-owned package changes.
After installation, remove the installer file if you no longer need it:
rm ~/miniconda.sh
Step 5: initialize conda for your shell
Initialize conda for Bash:
$HOME/miniconda3/bin/conda init bash
Then start a new shell session or reload your shell configuration. On a remote VPS, keep your current terminal open until you confirm the new shell behaves correctly.
Check the version:
conda --version
If the command is not found, use the full path to conda or open a new login shell.
Step 6: create a project environment
Do not install project packages into base. Create a named environment:
conda create -n analytics python=3.12
conda activate analytics
python --version
Each project should have its own environment. That prevents one application from accidentally changing another application’s dependencies.
Step 7: export the environment
When the environment is ready, export it so you can reproduce it later:
conda env export > environment.yml
Commit the environment file with the project if appropriate. That gives future deployments a clear dependency record.
Step 8: update conda carefully
Update conda from the base environment when you have a maintenance window:
conda update -n base conda
Do not update everything blindly on a production VPS. Environment updates can change dependency versions. Test application behavior before and after upgrades.
Troubleshooting conda on a VPS
If conda works only when you use the full path, your shell initialization probably has not loaded yet. Open a new login shell, reconnect over SSH, or review the shell file that conda init changed. Keep the old session open while testing so you do not strand yourself in a broken environment.
If package solves become slow, reduce the environment size, pin only the versions that matter, and avoid mixing too many channels without a reason. Large scientific environments can take time to solve, especially on smaller VPS plans.
If an application starts from systemd, cron, or another service manager, remember that it may not load your interactive shell settings. Use explicit paths or activation steps in the service wrapper, and test the same command from the same user account that will run the workload.
Common mistakes
Installing into system Python
Do not mix conda packages into Ubuntu’s system Python. Keep conda in its own directory and environments.
Running everything as root
A per-user conda install is usually safer. Use root only when your operational design requires a shared managed installation.
Skipping hash verification
Installer verification protects you from corrupted downloads and wrong files. It is a small step with high value.
Working in base
The base environment should manage conda itself. Project packages belong in project environments.