InfluxDB 3

Open Marketplace in the Azure Portal, search for InfluxDB 3, and select the SecureAnyCloud publisher entry. Click Create to begin the wizard.

On the Basics tab choose your subscription, target resource group, and region. The region must match the region your Azure Compute Gallery exposes the image in. Set the virtual machine name. Choose SSH public key as the authentication type, set the username to a name of your choice, and paste your SSH public key.

Standard_D2s_v3 is the recommended starting size. The Parquet columnar engine benefits from memory for query caching once real write throughput starts landing, and the 8 gigabyte RAM profile covers most single-node observability workloads comfortably. Scale up to Standard_D4s_v3 or Standard_D8s_v3 for heavier write rates or retention windows that measure in weeks rather than days.

On the Disks tab, choose Standard SSD as the OS disk type. The InfluxDB 3 data directory lives at /var/lib/influxdb3. If you expect to ingest more than a few gigabytes per day, attach a separate Premium SSD data disk now, and follow Section 16 after the server is running to move the data directory across.

On the Networking tab, select your existing virtual network and subnet. Attach a network security group that allows inbound TCP 22 from your management IP range, and inbound TCP 8181 only from the virtual network CIDR or the specific application server and Grafana subnets that need to talk to the server.

Do not expose 8181 to the public internet. Bearer token authentication is strong, but transport is plain HTTP unless you terminate TLS in front of the server as described in Section 18. An exposed time series database with a scraped token is an indefinite compromise.

On the Management, Monitoring, and Advanced tabs, keep the defaults. Click Review + create, wait for validation to pass, then click Create. Deployment takes around two minutes.

If you prefer the command line, accept the Marketplace terms once, then deploy from the Marketplace image URN.

RG="influxdb-prod" LOCATION="eastus" VM_NAME="influxdb-01" ADMIN_USER="influxops" IMAGE_URN="sac1647283583153:influxdb-3-ubuntu-22-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create \
  --resource-group "$RG" \
  --name influxdb-vnet \
  --address-prefix 10.40.0.0/16 \
  --subnet-name influxdb-subnet \
  --subnet-prefix 10.40.1.0/24 az network nsg create --resource-group "$RG" --name influxdb-nsg az network nsg rule create \
  --resource-group "$RG" --nsg-name influxdb-nsg \
  --name allow-ssh-mgmt --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" \
  --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create \
  --resource-group "$RG" --nsg-name influxdb-nsg \
  --name allow-influxdb-vnet --priority 110 \
  --source-address-prefixes 10.40.0.0/16 \
  --destination-port-ranges 8181 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:influxdb-3-ubuntu-22-04:default:latest
az vm create \
  --resource-group "$RG" \
  --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_D2s_v3 \
  --storage-sku StandardSSD_LRS \
  --admin-username "$ADMIN_USER" \
  --ssh-key-values "$SSH_KEY" \
  --vnet-name influxdb-vnet --subnet influxdb-subnet \
  --nsg influxdb-nsg \
  --public-ip-address "" \
  --os-disk-size-gb 32

The --public-ip-address "" flag keeps the server off the public internet. Reach it through a bastion host or your existing private connectivity.

After deployment, find the private IP of the new virtual machine. From a host inside the same virtual network, connect with:

ssh influxops@<private-ip>

The first login may take a few seconds while cloud-init finalises. Once you have a shell, systemd has already started the server, and the first-boot oneshot has already generated the per-VM admin token and created the default database.

The admin token is written by the influxdb-firstboot.service systemd oneshot the very first time the virtual machine boots. It lives in a single file, readable only by root. Print it with:

sudo cat /stage/scripts/influxdb-credentials.log

The output looks like this:

port=8181 default_database=sac token=apiv3_aB3dQ9pK1xVnE7sT3uYrL6cZw0jHm4f8x_g7TpLk2vR sample_connect=curl -H "Authorization: Bearer apiv3_..." http://localhost:8181/health

Every virtual machine deployed from this image has a different token. The token is an opaque bearer credential, not a password pair. Treat it like a secret API key: store it in your secrets manager, never check it into version control, and rotate it before production as described in Section 12.

• InfluxDB 3 Core: the version is pinned at build time (printed by influxdb3 --version). It is a Rust time series engine with columnar Parquet storage, the DataFusion query engine, and the HTTP API.
• Ubuntu 22.04 LTS: the base operating system.
• systemd units: influxdb3.service and influxdb-firstboot.service handle process supervision and first-boot token generation.

The influxdb3 binary is at /usr/bin/influxdb3, installed from the official InfluxData APT repository at repos.influxdata.com/debian stable main. Runtime configuration is passed as CLI flags expanded from the systemd EnvironmentFile at /etc/influxdb3/influxdb3.env. There is no traditional YAML or INI config file. The first-boot oneshot runs with Type=oneshot and RemainAfterExit=yes, gated by the sentinel file /var/lib/influxdb3/.firstboot-done, so it runs exactly once per virtual machine.

Each entry lists the path, then owner and mode, then purpose:

• /usr/bin/influxdb3 (root:root 0755): the InfluxDB 3 server and CLI. It is the same binary, and subcommands select the mode.
• /etc/influxdb3/influxdb3.env (root:root 0644): the systemd EnvironmentFile holding the node id, object store type, data dir, and HTTP bind address.
• /etc/systemd/system/influxdb3.service (root:root 0644): the InfluxDB 3 server unit, which expands the env file into the ExecStart flags.
• /etc/systemd/system/influxdb-firstboot.service (root:root 0644): the oneshot that generates the admin token and creates the default database.
• /usr/local/sbin/influxdb-firstboot.sh (root:root 0750): the first-boot script, invoked by the oneshot.
• /usr/local/sbin/influxdb-start.sh, influxdb-stop.sh, setEnv.sh (root:root 0755): convenience wrappers around systemctl.
• /var/lib/influxdb3/ (influxdb:influxdb 0750): the data directory, holding Parquet segments, the write-ahead log, and object store metadata.
• /var/lib/influxdb3/.firstboot-done (influxdb:influxdb 0644): the sentinel. Its presence means first boot has already run.
• /stage/scripts/influxdb-credentials.log (root:root 0600): the generated admin token, readable by root only.

InfluxDB 3 Core uses the local filesystem object store (--object-store file) with the data directory pointing at /var/lib/influxdb3. The server writes Parquet segments into subdirectories inside that tree, and compaction is automatic. Logs go to the systemd journal. View them with journalctl -u influxdb3 -f.

Use systemd directly:

sudo systemctl start influxdb3
sudo systemctl stop influxdb3
sudo systemctl restart influxdb3
sudo systemctl status influxdb3

Or use the helper scripts:

sudo /usr/local/sbin/influxdb-start.sh
sudo /usr/local/sbin/influxdb-stop.sh

Tail the server logs through the journal:

sudo journalctl -u influxdb3 -f

The first-boot oneshot is separate. It runs exactly once, on the first boot, and should show as active (exited) from then on:

sudo systemctl status influxdb-firstboot

The HTTP /health endpoint is unauthenticated, and it returns 200 with a small JSON body when the server is ready:

curl http://localhost:8181/health

Expected output is similar to {"status":"ok"} or OK depending on version. A 200 response means the HTTP listener is bound, the query engine is initialised, and the object store is reachable.

InfluxDB 3 accepts writes in the InfluxDB line protocol. Writes do not use SQL INSERT. They use line protocol over HTTP. A single measurement point looks like this:

measurement,tag_key=tag_value field_key=field_value timestamp_nanoseconds

POST one or more lines to /api/v3/write_lp?db=<database>:

TOKEN="$(sudo awk -F= '/^token=/ {print $2}' /stage/scripts/influxdb-credentials.log)" curl -X POST "http://localhost:8181/api/v3/write_lp?db=sac&precision=nanosecond" \
  -H "Authorization: Bearer $TOKEN" \
  --data-binary "temperature,location=office value=23.5"

To batch many lines in a single request, put one point per line in the body. Timestamps are optional. If you omit them, the server stamps the write at its current time. The precision query parameter accepts nanosecond, microsecond, millisecond, and second.

Examples with common client libraries:

# Python with the influxdb3-python client from influxdb_client_3 import InfluxDBClient3, Point client = InfluxDBClient3( host="http://<vm-ip>:8181", token="<your-token>", database="sac", ) point = Point("temperature").tag("location", "office").field("value", 23.5) client.write(point)

// Node with axios const axios = require("axios"); await axios.post( "http://<vm-ip>:8181/api/v3/write_lp?db=sac", "temperature,location=office value=23.5", { headers: { Authorization: "Bearer <your-token>" } }, );

InfluxDB 3 speaks SQL natively. Query it through the HTTP endpoint /api/v3/query_sql:

curl -X POST "http://localhost:8181/api/v3/query_sql" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"db":"sac","q":"SELECT * FROM temperature ORDER BY time DESC LIMIT 10"}'

Or use the CLI that ships with the binary:

sudo influxdb3 query \
  --host http://localhost:8181 \
  --token "$TOKEN" \
  --database sac \
  "SELECT * FROM temperature ORDER BY time DESC LIMIT 10"

The response is a JSON array of rows by default. With the CLI, use --format csv or --format pretty for alternative output.

For clients and dashboards that still speak InfluxQL (the v1.x query language), InfluxDB 3 exposes /api/v3/query_influxql. This is the compatibility path for existing Grafana dashboards and legacy tooling.

curl -X POST "http://localhost:8181/api/v3/query_influxql" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"db":"sac","q":"SELECT mean(value) FROM temperature WHERE time > now() - 1h GROUP BY time(5m)"}'

New applications should prefer SQL. InfluxQL is there so you do not have to rewrite every dashboard on day one of a migration.

Bearer tokens do not expire on their own. Rotate the token generated at first boot before production, and then on whatever schedule your security policy requires. The rotation pattern is create a second admin token, switch your clients over, delete the first.

Never delete the only admin token before the new one is known to work, because the server has no superuser fallback.

# 1. Create a second admin token with a distinct name
sudo influxdb3 create token --admin --token "$TOKEN" --name "admin-rotated-$(date +%Y%m%d)" --format json
# Copy the token value from the output and update /stage/scripts/influxdb-credentials.log.
# 2. List current tokens so you can confirm the rotation and identify the old one
sudo influxdb3 show tokens --token "<new-admin-token>"
# 3. Delete the old token by its name (the firstboot default name is _admin)
sudo influxdb3 delete token --token-name "_admin" --token "<new-admin-token>"

You can also regenerate the existing _admin token in place (same name, new value) with sudo influxdb3 create token --admin --regenerate --format json and confirming at the prompt. In either case, update the configuration of every client that cached the old token.

InfluxDB 3 Core exposes a single token type: admin. Scoped tokens with db:write or db:read permissions are an InfluxDB 3 Enterprise feature and are not available in Core. For a Core deployment, you have three practical options for handling application access.

Option A: one admin token per application

Create a distinct admin token for each application with a descriptive name, and give each application its own token. Every token has full server access, but you can rotate and revoke per application without touching any other client.

sudo influxdb3 create token --admin --token "$TOKEN" --name "grafana-prod" --format json
sudo influxdb3 create token --admin --token "$TOKEN" --name "app-writer-eu" --format json
sudo influxdb3 create token --admin --token "$TOKEN" --name "batch-ingest" --format json

When the Grafana host is decommissioned, this command revokes just that token: sudo influxdb3 delete token --token-name "grafana-prod" --token "$TOKEN".

Option B: reverse proxy with per-application credentials

Place nginx or Caddy in front of InfluxDB 3 on the same VM, and terminate TLS there. Use the proxy's auth layer (basic auth, mTLS client certificates, or an OAuth2 introspection endpoint) to gate each application by its own credential. The proxy injects the single InfluxDB admin token on every forwarded request. This is the pattern that gives you real least privilege on Core.

Option C: upgrade to Enterprise if scoped tokens are a hard requirement

InfluxDB 3 Enterprise supports scoped tokens natively through the same influxdb3 create token command with --permission flags. If your security model requires database-level or table-level access control enforced by the database itself, plan a migration to Enterprise.

Rotate every application token on the same cadence as the admin token regardless of which option you choose.

InfluxDB 3 has no traditional config file. Runtime options are CLI flags expanded from /etc/influxdb3/influxdb3.env inside the systemd unit. To change a runtime option such as the bind address, data directory, or node id, edit the env file:

sudo vi /etc/influxdb3/influxdb3.env
sudo systemctl restart influxdb3

To change anything systemd itself controls (user, ulimit, resource constraints, additional flags), use a drop-in override rather than editing the shipped unit:

sudo systemctl edit influxdb3

An editor opens on an empty drop-in file at /etc/systemd/system/influxdb3.service.d/override.conf. Add only the sections you want to change, for example:

[Service] LimitNOFILE=131072 Environment="INFLUXDB3_LOG_LEVEL=debug"

Save and exit. systemd reloads and applies the override on the next restart. Drop-in overrides survive package upgrades because they do not touch the base unit the APT package manages.

Grafana's built-in InfluxDB data source speaks to the InfluxDB 3 HTTP API directly. In Grafana, do the following:

• Click Add data source and pick InfluxDB.
• Set Query language to InfluxQL for compatibility with legacy dashboards, or to SQL if your Grafana version supports the Flight SQL dialect against InfluxDB 3.
• Set URL to http://<vm-private-ip>:8181.
• Under Auth, toggle Custom HTTP Headers and add Authorization with value Bearer <read-only-token>. Use the read-only token from Section 13, not the admin token.
• Set Database to SecureAnyCloud, or whichever database the dashboard targets.
• Click Save & Test. Grafana confirms the data source is reachable.

Now you can build panels. This query is a good smoke test: SELECT mean(value) FROM temperature WHERE $__timeFilter(time) GROUP BY time($__interval)

For production workloads larger than the OS disk can comfortably hold, attach a Premium SSD data disk, then move the data directory across.

# 1. Identify the new block device (look for the unpartitioned disk) lsblk
# 2. Format and mount it
sudo mkfs.ext4 /dev/sdc
sudo mkdir -p /data
sudo mount /dev/sdc /data
sudo blkid /dev/sdc
# copy the UUID into /etc/fstab for persistence
# 3. Stop InfluxDB and move the data directory
sudo systemctl stop influxdb3
sudo rsync -aAX /var/lib/influxdb3/ /data/influxdb3/
sudo chown -R influxdb:influxdb /data/influxdb3
sudo mv /var/lib/influxdb3 /var/lib/influxdb3.bak
# 4. Point the env file at the new location
sudo sed -i 's|INFLUXDB3_DATA_DIR=.*|INFLUXDB3_DATA_DIR=/data/influxdb3|' \
  /etc/influxdb3/influxdb3.env
# 5. Restart and verify
sudo systemctl start influxdb3
sudo journalctl -u influxdb3 -f

Delete /var/lib/influxdb3.bak only after the server has started cleanly and your queries work.

Cannot connect on 8181 from another host

Verify the server is bound to 0.0.0.0 rather than 127.0.0.1: sudo ss -tlnp | grep 8181. If only 127.0.0.1 is shown, check that the systemd env file has INFLUXDB3_HTTP_BIND_ADDR=0.0.0.0:8181 and restart. If the server is bound correctly, the problem is your Azure NSG. Confirm that inbound TCP 8181 is allowed from the caller's CIDR.

Write returns 401 or 403

The bearer token is missing, malformed, or has been deleted. Re-read /stage/scripts/influxdb-credentials.log to confirm the current token, and be sure the Authorization: Bearer <token> header is present on every write. Tokens are long opaque strings, and copying only part of one is a common mistake.

Write returns 404 for a database

The target database has not been created on this instance. The first-boot oneshot creates SecureAnyCloud as the default. Create any other database explicitly:

sudo influxdb3 create database <name> --host http://localhost:8181 --token "$TOKEN"

Query returns zero rows even though writes succeeded

There are two usual causes. The first is a time range filter that does not cover when the data was written. This is especially common if you relied on a time field in the line protocol rather than the server's clock. The second is that the write-ahead log has not yet flushed to Parquet. Writes are durable in the WAL immediately, but queries read from Parquet on disk, and there is a short flush interval. Waiting a few seconds and retrying usually resolves the second case.

Disk usage climbs faster than expected

Compaction is automatic but not instantaneous. Check the size of /var/lib/influxdb3/ over time and compare it against your ingest rate. If the directory grows much faster than ingest alone would explain, inspect journalctl -u influxdb3 for compaction errors. For very high-cardinality workloads, consider increasing the disk size before trying to tune compaction settings.

InfluxDB 3 refuses to start after an env file change

Run sudo systemctl status influxdb3 and read the last journal lines. A common cause is a typo in the env file that makes the expanded CLI flag invalid. Fix the file, then run systemctl restart influxdb3.

Never run this server without tokens. The bootstrap token is generated at first boot, and authentication is enforced from that moment. Rotating the admin token before production is recommended, but the token guard is already active out of the box.

Restrict port 8181 in the NSG to your application subnets and Grafana hosts. The public internet should never reach an observability database.

Terminate TLS in front of the server by installing nginx or Caddy on the same VM listening on 443 and forwarding to 127.0.0.1:8181, and let Certbot or Caddy's automatic TLS keep a valid certificate in place. The InfluxDB 3 HTTP listener is plain HTTP, so do not expose it directly to anything outside the VM over a network you do not trust.

Use per-application tokens with least-privilege permissions. An application that only writes one database never needs an admin or read token, and a Grafana user never needs write.

Rotate tokens periodically. There is no automatic rotation, so put it on your security calendar.

Keep the system patched. The APT sources stay configured. Run sudo apt-get update && sudo apt-get upgrade regularly to pick up InfluxData and Ubuntu security updates.

SecureAnyCloud provides 24/7/365 expert technical support for this image, with a guaranteed response within 24 hours and a one-hour average for critical issues. Contact sales@secureanycloud.com.

InfluxDB 3 Core is licensed under the MIT and Apache 2.0 licences by InfluxData. This image is a repackaged upstream distribution provided by SecureAnyCloud. Additional charges apply for the preconfigured image, ongoing maintenance, and the 24/7 support contract.

The published version of this guide is at secureanycloud.com/guides/influxdb-3-on-ubuntu-22-04-azure.

InfluxDB is a registered trademark of InfluxData, Inc.

Deploy on Azure

Launch InfluxDB 3 Core on Ubuntu 22.04 on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com