InfluxDB 2.9.1

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick InfluxDB 2.9.1 on Ubuntu 24.04 as the software version and select your Region. Choose Launch through EC2, then select m5.large (or larger for heavy write loads), your key pair and the security group described above.

InfluxDB stores your data on the root volume under /var/lib/influxdb. Give the root volume the space your retention needs, for example 100 GiB instead of the default 8 GiB. The root file system grows to fill the volume on first boot.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=100,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=influxdb}]'

Connect over SSH as the ubuntu user:

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot takes a few seconds. After it finishes, InfluxDB, nginx and the first boot unit are all active:

systemctl is-active influxdb nginx influxdb-firstboot

active active active

nginx is the only network listener besides SSH. influxd listens on 127.0.0.1:8086 only:

sudo ss -tlnp | awk 'NR==1 || /nginx|sshd|influxd/' | awk '{print $1, $4}'

State Local LISTEN 0.0.0.0:443 LISTEN 0.0.0.0:80 LISTEN 0.0.0.0:22 LISTEN 127.0.0.1:8086 LISTEN [::]:443 LISTEN [::]:80 LISTEN [::]:22

Check the release that each binary reports:

influxd version influx version

InfluxDB v2.9.1 (git: d4fa1941fd) build_date: 2026-10-20T11:33:22Z Influx CLI 2.8.0 (git: 8cdf401) build_date: 2026-10-20T11:36:09Z

sudo cat /root/influxdb-credentials.txt

The file holds the address InfluxDB is served at (your instance's public IP address by default) and the secrets generated on this instance:

# InfluxDB 2.9.1 - generated on first boot by influxdb-firstboot.service. Unique to this instance; keep it safe.
# The web UI and the HTTP API are served over HTTPS by nginx with this instance's own self-signed certificate # (browsers warn once; API clients need the certificate or an insecure-skip-verify option). INFLUXDB_URL=https://<public-ip>/ influxdb.host=<public-ip> influxdb.username=admin influxdb.password=<32 letters and digits> influxdb.org=sac influxdb.bucket=metrics influxdb.token=<64 letters and digits> # The token above is the all-access OPERATOR token. Create narrower tokens for applications: # https://<public-ip>/ -> Load Data -> API Tokens (or: influx auth create --help) # On the instance, influxd also answers on loopback: http://127.0.0.1:8086 # Change the host name:
sudo influxdb-set-host <dns-name>
# User guide: https://secureanycloud.com/stacks/influxdb-2-9-1/

First boot created the organization SecureAnyCloud, the bucket metrics (infinite retention) and the user admin. It also wrote an hour of demo points (sac_demo) so the UI has something to show. The onboarding endpoint now reports that setup is complete:

curl -sk https://127.0.0.1/api/v2/setup

{ "allowed": false }

Open INFLUXDB_URL in your browser. The certificate is self-signed and generated on your instance, so accept the browser warning once, or use your own name and certificate (Step 10). Sign in as admin with influxdb.password:

Open the Data Explorer to see the sac_demo measurement in the metrics bucket. Pick the measurement and the cpu field, then choose Submit:

Load Data → API Tokens lists the operator token (shown as admin's Token). Use this page to create read or write tokens scoped to single buckets for your applications. Tokens are stored hashed, so a token's value is shown only once, when you create it:

On the instance, the CLI talks to influxd directly over loopback. Pass the token in the INFLUX_TOKEN environment variable, not on the command line:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)" influx bucket list --host http://127.0.0.1:8086 --org sac

ID Name Retention Shard group duration Organization ID Schema Type 0462d13e5a57d7e9 _monitoring 168h0m0s 24h0m0s 70773f8d8b21cdb3 implicit 5aebfc3bfe7d6154 _tasks 72h0m0s 24h0m0s 70773f8d8b21cdb3 implicit 5e27ce71d7c8965d metrics infinite 168h0m0s 70773f8d8b21cdb3 implicit

Count the demo points with a Flux query:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)" influx query --host http://127.0.0.1:8086 --org sac \
  'from(bucket:"metrics") |> range(start:-24h) |> filter(fn:(r) => r._measurement == "sac_demo" and r._field == "cpu") |> count()' \
  | awk '/sac_demo/{print "sac_demo cpu points:", $NF}'

sac_demo cpu points: 60

To create a narrower token for an application, see influx auth create --help (for example --write-bucket <bucket-id>). You can also use Load Data → API Tokens in the UI.

Remote clients use https://<public-ip>/ (or your own DNS name) with a token. The commands below write one point in line protocol and read it back with Flux. The token is read into a shell variable and handed to curl as a header file, so it never appears on a command line:

TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)" HOST="$(sudo sed -n 's/^influxdb.host=//p' /root/influxdb-credentials.txt)" HDR="$(mktemp)"; printf 'Authorization: Token %s\n' "$TOKEN" > "$HDR" curl -s -o /dev/null -w 'write: HTTP %{http_code}\n' --cacert /etc/nginx/ssl/influxdb.crt --resolve "$HOST:443:127.0.0.1" \
  -X POST -H "@$HDR" --data-binary "weather,site=lab temperature=21.5 $(date +%s)" \
  "https://$HOST/api/v2/write?org=sac&bucket=metrics&precision=s" curl -s --cacert /etc/nginx/ssl/influxdb.crt --resolve "$HOST:443:127.0.0.1" -X POST -H "@$HDR" \
  -H 'Accept: application/csv' -H 'Content-Type: application/vnd.flux' \
  --data 'from(bucket:"metrics") |> range(start:-10m) |> filter(fn:(r) => r._measurement == "weather") |> last()' \
  "https://$HOST/api/v2/query?org=sac" | awk -F, '/weather/{print "read back:", $7, $8, $9}' rm -f "$HDR"

write: HTTP 204 read back: 21.5 temperature weather

From another machine, copy /etc/nginx/ssl/influxdb.crt from the instance and pass it as the CA certificate (--cacert for curl, ssl_ca for Telegraf's [[outputs.influxdb_v2]]). Alternatively, use your own certificate (Step 10). A Telegraf output looks like this:

[[outputs.influxdb_v2]] urls = ["https://<public-ip>"] token = "$INFLUX_TOKEN" organization = "sac" bucket = "metrics" tls_ca = "/etc/telegraf/influxdb.crt"

Requests without a token, or with a wrong one, are refused:

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/api/v2/buckets
curl -sk -o /dev/null -w '%{http_code}\n' -H 'Authorization: Token admin' https://127.0.0.1/api/v2/buckets

401 401

Nobody can use the onboarding endpoint to claim the instance, either through nginx or on InfluxDB's own port:

curl -sk -o /dev/null -w 'via nginx: %{http_code}\n' -X POST -H 'Content-Type: application/json' \
  --data '{"username":"x","password":"Sample-Passw0rd-x","org":"x","bucket":"x"}' https://127.0.0.1/api/v2/setup
curl -s -X POST -H 'Content-Type: application/json' \
  --data '{"username":"x","password":"Sample-Passw0rd-x","org":"x","bucket":"x"}' http://127.0.0.1:8086/api/v2/setup | grep -o '"message": "[^"]*"'

via nginx: 403 "message": "onboarding has already been completed"

Check the settings that harden InfluxDB itself:

grep -E '^(http-bind-address|use-hashed-tokens|strong-passwords|hardening-enabled|template-file-urls-disabled|reporting-disabled)' /etc/influxdb/config.toml

http-bind-address = "127.0.0.1:8086" use-hashed-tokens = true strong-passwords = true hardening-enabled = true template-file-urls-disabled = true reporting-disabled = true

InfluxDB and nginx cannot reach the instance metadata service, and Flux refuses to fetch link-local or private addresses:

systemctl show -p IPAddressDeny influxdb nginx export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)" OUT="$(influx query --host http://127.0.0.1:8086 --org sac \
  'import "experimental/http" import "array" array.from(rows: [{v: string(v: http.get(url: "http://169.254.169.254/latest/meta-data/").statusCode)}])' 2>&1 || true)" grep -o 'no such host' <<<"$OUT"

IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 IPAddressDeny=168.63.129.16/32 169.254.169.254/32 fd00:ec2::254/128 no such host

You can also run the full self-test that the image build runs:

sudo influxdb-selftest

• Retention: the metrics bucket keeps data forever. Set a retention period in the UI (Load Data → Buckets → Settings) or with influx bucket update --id <bucket-id> --retention 30d.
• More users: use Settings → Members in the UI, or run influx user create followed by influx user password, which prompts for the password. Passwords must be at least 8 characters and mix upper case, lower case, digits or symbols.
• Backups: influx backup /path/to/backup --host http://127.0.0.1:8086 (with INFLUX_TOKEN set as in Step 6) writes a full backup, including the metadata needed to restore users and tokens. Keep the backup safe. EBS snapshots of the root volume are an alternative.

Point a DNS name at the instance, then make it the served name. The command writes a new self-signed certificate for that name and adds it to the names nginx answers for:

sudo influxdb-set-host influx.example.com

To use a certificate from your own CA or from Let's Encrypt, replace /etc/nginx/ssl/influxdb.crt and /etc/nginx/ssl/influxdb.key, keeping the key mode 0600. Then run sudo systemctl reload nginx. Clients now trust the certificate without --cacert.

Change the admin password in the UI (user menu → Change Password) or with the CLI, which prompts for the new password:

export INFLUX_TOKEN="$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)" influx user password --host http://127.0.0.1:8086 --name admin

To retire the operator token, create a new all-access token in Load Data → API Tokens. Update /root/influxdb-credentials.txt and your clients, then delete the old token. Keep at least one all-access token.

• InfluxDB server: /usr/local/bin/influxd, unit influxdb.service, user influxdb
• Configuration: /etc/influxdb/config.toml
• Data (bolt, sqlite, engine): /var/lib/influxdb
• influx CLI: /usr/local/bin/influx
• nginx site: /etc/nginx/sites-available/sac-influxdb, /etc/nginx/influxdb-proxy.conf, /etc/nginx/influxdb-host.conf
• TLS certificate and key: /etc/nginx/ssl/influxdb.crt, /etc/nginx/ssl/influxdb.key (mode 0600)
• Host name helper: /usr/local/sbin/influxdb-set-host
• Self-test: /usr/local/sbin/influxdb-selftest
• Credentials: /root/influxdb-credentials.txt (mode 0600)
• License and build record: /usr/share/doc/influxdb/LICENSE, /usr/share/doc/influxdb/BUILD-PROVENANCE.txt

Read the logs with journalctl -u influxdb and in /var/log/nginx/.

Never empty /var/lib/influxdb on a running instance and start InfluxDB by hand. An InfluxDB with no data serves the unauthenticated onboarding endpoint. The influxdb.service unit refuses to start without the ready marker that first boot writes.

• Allow port 22 in the security group from your own networks only, and open 80 and 443 only to the clients and people that need InfluxDB.
• Give each application its own token scoped to the buckets it needs, and keep the operator token for administration.
• Use your own DNS name and a certificate your clients trust (Step 10).
• Keep the operating system patched. Unattended security upgrades are on, and sudo apt-get update && sudo apt-get upgrade applies everything else.