.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Add Grafana's APT repository, then install the package. That is most of the install on Ubuntu 24.04 and it takes a few minutes on a fresh VPS. Going through the repository also gets you a systemd unit and a package-managed upgrade path, plus config at the paths every piece of Grafana documentation assumes, which on Ubuntu means /etc/grafana.
This walks through a clean install of Grafana 13.x on Ubuntu 24.04 LTS, from the repository key through to a working login. Every command here is run as a normal user with sudo.
What you need before you install
A VPS running Ubuntu 24.04 LTS, sudo access and a public IP. Grafana's documented minimum is 512 MB of memory and one CPU core. That is genuinely enough for a handful of dashboards. Memory pressure in a real setup comes from whatever you query, so size for Prometheus first if Prometheus is sharing the box.
Grafana ships with SQLite as its internal database, which is fine for a single instance. MySQL 8.0+ and PostgreSQL 12+ are the supported alternatives once you outgrow it. Nothing in this guide needs a separate database.
If you're building the box from nothing, get user creation and SSH hardening out of the way first. Doing them halfway through a Grafana install is how you end up with a half-configured service and a shell you can't get back into.
Install Grafana from the APT repository
Add the Grafana repository
Start with the tools APT needs to fetch a signed repository over HTTPS. On a minimal Ubuntu image wget and gnupg are often missing.
sudo apt-get install -y apt-transport-https wget gnupgNow the signing key. The current key is served as gpg-full.key and it belongs in /etc/apt/keyrings/grafana.asc.
sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
sudo chmod 644 /etc/apt/keyrings/grafana.ascOlder instructions pipe the key into apt-key add. That command was deprecated years ago and removed from modern Ubuntu, so it fails and leaves you with a key APT refuses to trust. There is a middle generation of guides pointing at /usr/share/keyrings/grafana.gpg, and those still work fine. The keyrings path above is what Grafana documents today.
A short aside on why that changed, since it explains the whole keyrings directory. A key added through apt-key was trusted for every repository configured on the machine, which meant a compromised third-party repo could sign packages claiming to come from Ubuntu itself. The signed-by option in the line below scopes one key to one repository. That is all it does, and it is the only reason the command looks the way it does.
Add the repository itself, pinned to that key file:
echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.listInstall the package
sudo apt-get update
sudo apt-get install grafanaThat pulls the current stable release, which as of writing is Grafana 13.x.
Grafana ships a new minor version every other month with patch releases in between. Each minor gets nine months of support. The last minor of a major line gets fifteen. Because the package came from the repo, apt-get upgrade keeps you current with no extra work.
OSS or Enterprise package names
The grafana package is the open source build. grafana-enterprise is the Enterprise build and comes from the same repository. The Enterprise package runs perfectly well with no licence, behaving as OSS Grafana until you apply one, which is why a fair number of tutorials install it by default.
Install grafana unless you already have an Enterprise licence in hand. The official Debian and Ubuntu install docs list both package names next to the beta and nightly repository lines, if you want either of those. Switching later is an apt install grafana-enterprise away and the data directory carries over, so there's nothing to plan around now.
What the grafana package creates on disk
Here is what lands where.
| Path | What it holds |
|---|---|
/etc/grafana/grafana.ini | Your config file. Every line ships commented out with a leading semicolon. |
/usr/share/grafana | The install home, including conf/defaults.ini and the bin/grafana binary. |
/var/lib/grafana | Data directory: the SQLite database and the plugins directory. |
/var/log/grafana | Log directory, with grafana.log inside it. |
/etc/default/grafana-server | Environment file the systemd unit reads. |
It also creates a grafana system user and group, and the service runs as that user. Nothing here runs as root, which is why a bind mount or a log directory you create by hand needs its ownership set before Grafana can write to it.
Open /etc/default/grafana-server once. It sets GRAFANA_HOME, CONF_FILE, DATA_DIR, LOG_DIR, PLUGINS_DIR, PID_FILE_DIR, MAX_OPEN_FILES=10000 and RESTART_ON_UPGRADE=true. The systemd unit passes those into Grafana as cfg:default.paths.* arguments, which land in the defaults layer of Grafana's config precedence.
That precedence has one practical consequence. Your /etc/grafana/grafana.ini and any GF_* environment variable still override those arguments, so setting [paths] logs in grafana.ini really does move the log file, even though the unit reads like it's pinning /var/log/grafana. The guide to where Grafana logs live and how to read them starts from that same precedence chain. Read the environment file before you write a systemd drop-in, because half of what people override in a drop-in is already set there.
Start Grafana and enable it at boot
The package installs the unit but doesn't start it. Reload systemd so it picks up the new unit file, then start and enable:
sudo systemctl daemon-reload
sudo systemctl start grafana-server
sudo systemctl enable grafana-server.serviceThe daemon-reload is in Grafana's own instructions and I run it out of habit, though dpkg triggers a reload on install anyway and I have never managed to break a start by skipping it. I don't know if it covers a case I haven't hit or if it's left over from older packaging.
Check it came up:
sudo systemctl status grafana-serverYou want active (running). If it's in a restart loop, the log tells you why almost immediately:
sudo journalctl -u grafana-server -n 50 --no-pagerThe two failures that come up most on a fresh install are a port already in use and a permissions problem on the data directory. Both print a clear line in the journal.
Check that Grafana is listening on port 3000
Before you go looking in a browser, confirm the process bound the port:
ss -tlnp | grep 3000You should see a line with *:3000 or 0.0.0.0:3000 and users:(("grafana",...)) at the end. An empty result means Grafana isn't listening, so go back to the journal. If the line is owned by a different process, something else grabbed 3000 first, which is routine on boxes already running Node apps; the guide to the Grafana default port and how to change it covers moving Grafana off it. That's one config key and a restart.
Then open http://YOUR_SERVER_IP:3000.
Log in and change the admin password
The default credentials are admin / admin. Grafana prompts you to change the password immediately after that first sign-in, and you should take the prompt rather than skipping it, because the default is the first thing any scanner tries against an exposed 3000.
Once you're in, the admin password lives under the user profile menu. There's no email reset for that account, so losing the password means a CLI command on the server; the writeup on the Grafana default login and how to change it has that command along with the container and Kubernetes cases. None of it is urgent today. It matters the first time you come back to a box six months later.
Setting admin_password in grafana.ini after Grafana has already started once does nothing at all. The admin user row exists in the database by then. That config value is only read when the row gets created.
grafana server and grafana cli replaced the hyphenated commands
Grafana consolidated its binaries into one. The single executable is /usr/share/grafana/bin/grafana, and the current commands are grafana server and grafana cli, two words each.
The old grafana-server and grafana-cli still exist as wrapper scripts, but they now print a deprecation warning:
Deprecation warning: 'grafana-cli' is deprecated and will be removed in a future release. Use the 'grafana cli' subcommand instead.So a plugin install is sudo grafana cli plugins install <plugin-id> and a password reset is sudo grafana cli admin reset-admin-password <new password>. There are a dozen or so other subcommands in the Grafana CLI reference, most of which you will never type.
The systemd unit is still called grafana-server.service. It did not get renamed. sudo systemctl restart grafana-server stays correct. The hyphenated grafana-cli is the one on its way out. Same string, two different things.
APT repo, .deb file or Docker: which install to pick
For a VPS where Grafana is the main job, I use the APT repository every time. The specific reason is unattended-upgrades. Grafana ships security patches often enough that I don't want to be the thing standing between a CVE and the box, and a repo install picks them up with no action from me.
Downloading the standalone .deb and running dpkg -i gives you the identical layout with no upgrade path. You're then checking for releases by hand every couple of months on a product that ships a minor every other month. The only place that makes sense is an air-gapped box where APT can't reach the internet.
Docker is the right answer when Grafana is one service among several on the same host, particularly if Prometheus and a couple of exporters are already in a compose file next to it. Config becomes environment variables and upgrades become an image tag bump. Logs land in docker logs and the whole stack moves to another host as one file. The walkthrough for running Grafana with Docker Compose goes through the volume and permission problems that come with that. What you pay is a layer of indirection over networking and file permissions, which buys you nothing when Grafana is the only service on the box.
Skipping the install entirely is also an option. The one-click Grafana VPS template on LumaDock deploys the package install above onto an NVMe instance with the service already running. That's the shortcut when you want a dashboard host up in a couple of minutes and don't much care how the key got there.
Firewall port 3000 so it isn't open to the internet
By default Grafana binds 0.0.0.0:3000, so the moment the service starts, anyone who scans your IP finds a login page. That page is unencrypted HTTP and, until you change it, has a well-known default password behind it.
If you only need access from your own IP while you set things up:
sudo ufw allow from YOUR_IP to any port 3000 proto tcp
sudo ufw enableOnce nginx is in front, don't expose 3000 at all. Set http_addr = 127.0.0.1 under [server] in /etc/grafana/grafana.ini, restart and let nginx be the only thing listening publicly. The firewall rule and the loopback bind are independent of each other; Grafana security best practices makes the case for keeping both. ss -tlnp | grep 3000 reads 127.0.0.1:3000 once the bind takes effect, which is the confirmation to wait for before you delete the ufw rule.
Put nginx and TLS in front of Grafana
Grafana can terminate TLS itself using protocol = https with cert_file and cert_key, and for a single instance that works. I still put nginx in front, because certificate renewal through certbot and HTTP to HTTPS redirects both want a real web server anyway.
The shape of it is a normal reverse proxy vhost pointing at http://127.0.0.1:3000, with two Grafana-specific details. First, Grafana's live features use WebSockets, so the proxy block needs proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade";. Second, Grafana builds every internal link from root_url, so set it to the public address before you go looking for broken redirects:
[server]
domain = grafana.example.com
root_url = https://grafana.example.com/Restart with sudo systemctl restart grafana-server after that edit. If you're serving Grafana from a subpath rather than its own hostname, you also need serve_from_sub_path = true and the subpath included in root_url.
The nginx and certbot mechanics are the same for any app on 3000, so rather than repeat them, the nginx reverse proxy and TLS walkthrough transfers directly. Swap the upstream port and the server name, keep the WebSocket headers and you're done.
With TLS terminated and 3000 closed, the next useful step is giving Grafana something to draw. A local Prometheus is the usual first data source, and the setup for that is in building a Grafana dashboard on Prometheus.
