InfluxDB

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for InfluxDB. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet.

Create or select a security group that allows inbound port 22 from your management network and inbound port 80 from the trusted networks that will reach the InfluxDB web interface. If you also want to talk to the raw InfluxDB HTTP API on its native port, open port 8086 to the same trusted networks. Do not open ports 80 or 8086 to the public internet without first terminating TLS and restricting access. Leave the root volume at the default size or larger.

Select Launch instance. First boot initialisation takes approximately one minute after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud InfluxDB Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens ports 22 and 80 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=influxdb-01}]'

The command prints a JSON document on success. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched. For InfluxDB 2 on Ubuntu 24.04, the SSH login user is ubuntu.

The first boot service runs after InfluxDB has started but before SSH is generally used. On a normal launch, the credentials file is in place a few seconds after the instance reaches Running. Show the file:

ssh <login-user>@<public-ip>
sudo cat /root/influxdb-credentials.txt

The plain-text file contains the following:

• The InfluxDB web URL and the raw InfluxDB API URL
• The administrator username, admin, and the administrator password
• The initial admin API token
• The org name and the name of the default bucket

Copy these values somewhere secure, such as a password manager or an encrypted vault. Do not commit them to source control.

Each command block in this guide that talks to InfluxDB begins by reading the admin token from the credentials file into a TOKEN shell variable, so every block is self-contained:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)" echo "token length: ${#TOKEN} org: $ORG"

InfluxDB exposes two endpoints that confirm the server is running, and both are reachable without authentication. The /ping endpoint returns HTTP 204 No Content if the daemon is up. The /health endpoint returns a JSON status document. Query both:

curl -sI http://127.0.0.1:8086/ping
curl -s http://127.0.0.1:8086/health

The health response reports "status":"pass" together with the installed InfluxDB version. For example:

{"name":"influxdb", "message":"ready for queries and writes", "status":"pass", "checks":[], "version": "v2.9.1", "commit": "d4fa1941fd"}

The /api/v2/setup endpoint reports {"allowed":false} on a fully initialised instance. This confirms that first boot has already run setup and the server is no longer awaiting initial provisioning. Check it:

curl -s http://127.0.0.1:8086/api/v2/setup

The image contains the following components:

• InfluxDB 2.9.x from repos.influxdata.com
• influx CLI 2.8.x from repos.influxdata.com
• nginx 1.24.x from the Ubuntu archive
• Ubuntu 24.04 LTS from the SecureAnyCloud golden base image
• SecureAnyCloud overrides: /etc/influxdb/config.toml and /etc/nginx/sites-available/influxdb, baked into the image

InfluxDB 2 ships as a self-contained Go binary, so the image has no JVM dependency and no separate runtime. nginx is the only adjacent process. It serves the InfluxDB user interface on the default HTTP port so that you can reach it without specifying a port number.

InfluxDB is self-contained, and its database files live on a dedicated EBS volume mounted at /var/lib/influxdb. The main directories and files that the image exposes are:

• /usr/bin/influxd: the InfluxDB server binary
• /usr/bin/influx: the InfluxDB command-line client
• /etc/influxdb/config.toml: SecureAnyCloud server configuration (bolt path, engine path, bind address)
• /var/lib/influxdb/influxd.bolt: the metadata KV store (orgs, users, tokens, buckets, dashboards)
• /var/lib/influxdb/engine/: the TSM time-series engine, write-ahead log and series index, on the dedicated data volume
• /etc/nginx/sites-available/influxdb: nginx reverse proxy config for port 80
• /var/log/syslog: combined log output via the systemd journal
• /root/influxdb-credentials.txt: per-instance admin password and token, mode 0600, root only

InfluxDB runs as the systemd service influxdb.service, and nginx runs as nginx.service. The first boot unit is influxdb-firstboot.service. It is skipped on every boot after the first because its sentinel lives at /var/lib/sac/data/influxdb-firstboot.done.

Manage the services with systemctl:

sudo systemctl status --no-pager influxdb
sudo systemctl is-active influxdb
sudo systemctl is-active nginx

Restart the server after editing configuration:

sudo systemctl restart influxdb

The InfluxDB service runs as the influxdb system user and owns /var/lib/influxdb. nginx runs as www-data and only listens on port 80, forwarding to InfluxDB on the loopback.

The InfluxDB user interface includes the Data Explorer, Dashboards, Tasks and Alerts pages. InfluxDB serves it on port 8086, and it is also reachable on port 80 through the nginx reverse proxy. Open port 80 in the security group from your management network, then open the following URL in your browser:

http://<public-ip>/

You are redirected to the sign-in page. Enter the administrator username admin and the administrator password from /root/influxdb-credentials.txt.

After you sign in, the Data Explorer opens. The left-hand nav rail gives you the Data Explorer, Notebooks, Dashboards, Tasks, Alerts and Settings pages.

The Data Explorer is the day-to-day query and exploration tool. Pick a bucket on the left, choose tag filters and a measurement, and set the time range. Then either run the query as Flux or switch to Script Editor to edit the Flux directly.

The Dashboards page is where you save query results as live charts. A freshly launched instance has no dashboards, and the empty state lets you click Create Dashboard to build the first one.

InfluxDB writes data over HTTP using the line protocol format. A line holds a measurement name, optional tag pairs, one or more field values and a timestamp. Push a single point to the default bucket using the admin API token:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)" curl -s -H "Authorization: Token $TOKEN" \
  -H 'Content-Type: text/plain' \
  -X POST "http://127.0.0.1:8086/api/v2/write?org=$ORG&bucket=default&precision=s" \
  --data-binary "cpu,host=server01,region=us-east-1 usage=0.42 $(date +%s)"

The endpoint returns HTTP 204 No Content on success. Send multiple points in a single request by separating each line of line protocol with a newline character.

Flux is InfluxDB 2's primary query language. The following query reads the last hour of cpu measurements from the default bucket. It computes the mean of the usage field over one-minute windows and returns the result as annotated CSV:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)" curl -s -H "Authorization: Token $TOKEN" \
  -H 'Content-Type: application/vnd.flux' \
  -X POST "http://127.0.0.1:8086/api/v2/query?org=$ORG" \
  --data-binary 'from(bucket:"default") |> range(start: -1h) |> filter(fn:(r)=>r._measurement=="cpu") |> aggregateWindow(every:1m, fn:mean)'

You can also run the same query from the Data Explorer page in the web interface. Select the bucket, the measurement and the time range in the visual builder, then switch to Script Editor to see and edit the underlying Flux.

If you know the InfluxDB 1.x query language, an InfluxQL compatibility endpoint is also available at /api/v2/query?type=influxql.

The influx command-line client is preinstalled. Create a local config that points at the running instance, then list the buckets you can read:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)" influx config create -n local -u http://127.0.0.1:8086 -t "$TOKEN" -o "$ORG" -a influx bucket list

The same CLI manages users, organisations, tokens, tasks, and dashboards. Run influx help for the full reference.

Never use the initial admin token for application traffic. Create a per-application token scoped to a single bucket, so that the application can only read and write the data it owns:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)" influx auth create \
  --org "$ORG" \
  --description "writer for the metrics-prod bucket" \
  --read-bucket "<bucket-id>" \
  --write-bucket "<bucket-id>"

Replace <bucket-id> with the id of the bucket the application should access. List buckets with influx bucket list.

The CLI prints the new token on success. Distribute it to your application through your secrets manager, never through source control.

For a production deployment, rotate the administrator password that was generated on first boot. The influx CLI prompts for the new value and writes it through the InfluxDB API:

influx user password -n admin
sudo sed -i "s|^influxdb.admin.pass=.*|influxdb.admin.pass=<new-password>|" /root/influxdb-credentials.txt

Store the new value in your secrets manager immediately. The file /root/influxdb-credentials.txt should not be considered your source of truth after first boot.

InfluxDB has two features for managing how long data is kept and how it is rolled up over time:

• Retention policies on each bucket drop points older than a fixed age. Set retention with influx bucket update --id <bucket-id> --retention 720h for thirty days.
• Tasks are scheduled Flux scripts that downsample, aggregate or copy data between buckets. They are visible and editable on the Tasks page of the web interface.

A typical downsampling task aggregates one-second raw data into one-minute averages every minute. It writes the result into a metrics-1m bucket with a longer retention and lets the raw bucket roll off after a few days.

The SecureAnyCloud image fronts InfluxDB with an nginx reverse proxy on port 80. For any deployment that carries customer traffic, terminate TLS in the same nginx so that credentials and data are not sent in clear text. A Let's Encrypt certificate gives you HTTPS without changing the InfluxDB configuration.

The following assumes that a DNS record points your fully qualified domain name at the instance's public IP address.

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d influxdb.your-domain.example \
  --non-interactive --agree-tos -m you@your-domain.example \
  --redirect

Certbot edits the SecureAnyCloud nginx site config to terminate TLS, and customer applications then talk to https://influxdb.your-domain.example.

Once the proxy is in place, restrict ports 80 and 8086 in the security group to the loopback and your application subnets.

InfluxDB has a built-in backup command that writes a portable archive of every bucket, user, organisation and dashboard on the instance:

TOKEN="$(sudo awk -F= '/^influxdb.admin.token=/ {print $2}' /root/influxdb-credentials.txt)" ORG="$(sudo awk -F= '/^influxdb.admin.org=/ {print $2}' /root/influxdb-credentials.txt)"
sudo mkdir -p /var/backups/influxdb
sudo influx backup --token "$TOKEN" --host http://127.0.0.1:8086 /var/backups/influxdb/$(date +%F)

Ship the archive to an Amazon S3 bucket or another object store.

For larger databases, take an Amazon EBS snapshot of the /var/lib/influxdb volume instead. A snapshot is faster. It is consistent for the InfluxDB engine if the daemon is briefly stopped, or if your workload tolerates a crash-consistent snapshot.

For kernel and package updates, Ubuntu's unattended-upgrades is enabled by default, so security patches apply automatically. To update InfluxDB itself, run sudo apt-get update && sudo apt-get install --only-upgrade influxdb2 influxdb2-cli and then restart the service.

This image is a single-node InfluxDB. For larger deployments:

• Grow the /var/lib/influxdb EBS volume and extend the filesystem when the database outgrows the initial disk
• Push higher-cardinality and longer-retention workloads to InfluxDB Cloud or InfluxDB Enterprise, both of which speak the same API
• Put the InfluxDB tier behind an Application Load Balancer with TLS termination, with the security group restricting ports 80 and 8086 to the load balancer and the application subnets
• Use scheduled Flux tasks together with the to(bucket) function to fan out a downsampled copy of the data into a second instance in another Availability Zone or Region for a warm standby

The official InfluxDB documentation at https://docs.influxdata.com covers schema design, hardware sizing and the Flux language in detail.

InfluxDB serves the HTTP API and the web user interface on the same port, and nginx exposes that same interface on the default HTTP port. Because of this single-port model, the security posture of those ports matters more than for most databases. Before taking customer traffic, apply the following:

• Never expose ports 80 or 8086 to the public internet without TLS in front. The web interface, the writes endpoint and the queries endpoint are all on those ports. Restrict the security group rules to your application subnets and management network.
• Rotate the administrator password using the rotation step above and store the new value in your secrets manager.
• Create per-application tokens scoped to the buckets they need, and stop using the initial admin token for application traffic. Only administrative operations should use the admin credential.
• Terminate TLS with the nginx reverse proxy so credentials and data are encrypted in transit.
• Set retention policies on every bucket so that data older than the operationally required window is dropped automatically.
• Back up /var/lib/influxdb regularly and test restores.