Infrahub Infrastructure Source of Truth on AWS User Guide

Overview

This guide covers the deployment and configuration of Infrahub on AWS using cloudimg AWS Marketplace AMIs. Infrahub, by OpsMill, is an open source infrastructure source of truth and infrastructure data management platform. You model your own infrastructure domain as a schema, store network, device, service and topology data as objects in a graph, and manage every change through branches and proposed changes - so your infrastructure data gets the same version-controlled, review-before-merge workflow that your code already has. A GraphQL API (and a REST API) make that data available to your automation and CI pipelines.

The cloudimg image ships the free and open source, Apache-2.0-licensed Infrahub run the officially supported way as the upstream containers pinned by image digest, backed by Neo4j Community Edition (GPLv3) as the graph database. It is a seven-container stack - the Infrahub server, two task workers and the task manager, plus the Neo4j graph database, a Redis cache, a RabbitMQ message queue and a PostgreSQL database for the task manager - orchestrated by Docker Compose under a single systemd service. Only the web application is published, on port 80; every backing service binds to the private container network only.

Because upstream ships an unusually large set of published default credentials, nothing here ships with a known secret: all seven of upstream's hardcoded defaults (admin password, admin API token, agent token, security key, and the graph, broker and task-database passwords) are regenerated uniquely for each instance on first boot, before the application is reachable. Anonymous read access to the object graph and product telemetry are both disabled. Backed by 24/7 cloudimg support.

Infrahub, Neo4j, Redis, RabbitMQ and PostgreSQL are trademarks of their respective owners. This image is produced by cloudimg and is not affiliated with, endorsed by, or sponsored by any of them. It ships the free and open source software, unmodified.

What is included:

• Infrahub 1.10.5 (the Apache-2.0-licensed server, task manager and workers), pinned by image digest
• Neo4j 2025.10.1 Community Edition (GPLv3) as the graph database that is Infrahub's source of truth, pinned by image digest
• Redis 8.4.0 cache, RabbitMQ 4.2.1 message queue and PostgreSQL 18 task-manager database, each pinned by image digest and reachable only on the private container network
• Docker Engine with a single published host port - 80 -> the Infrahub web application; the graph database, cache, message queue and PostgreSQL publish no host port
• docker.service and infrahub.service as systemd units, enabled and active on boot; infrahub-firstboot.service rotates every secret on the first boot
• The stateful data (graph store, task database, artifact object store and synchronised Git repositories) relocated onto a dedicated, independently-resizable data volume mounted at /var/lib/infrahub
• All seven of upstream's published default secrets regenerated uniquely per instance on first boot, never baked into the image; anonymous graph access and telemetry disabled
• Bundled third-party licence notices for Neo4j (GPLv3) and Redis (SSPLv1 elected) shipped at /usr/share/doc/cloudimg/third-party-licences/
• Ubuntu 24.04 LTS base with latest security patches applied at build time
• 24/7 cloudimg support

Prerequisites

• An active AWS account and an EC2 key pair in your target region
• A subscription to the Infrahub listing on AWS Marketplace
• A VPC and subnet, and a security group allowing inbound 22/tcp (SSH, from your admin network) and 80/tcp (the web application, from the networks that use it)

Recommended instance type: Infrahub is a seven-container stack that includes a JVM graph database. Upstream documents a minimum of 6 vCPU and 12 GB RAM and recommends 8 vCPU and 16 GB for a single-node deployment. For production use, launch this AMI on an m5.2xlarge (8 vCPU, 32 GB RAM) or larger instance. Smaller instances will struggle to bring the full stack up.

Connecting to your instance

This listing offers one or more operating-system variants. Connect over SSH as that variant's default login user, using your EC2 key pair:

Step 1: Subscribe and launch from AWS Marketplace

Sign in to the AWS Marketplace, search for Infrahub by cloudimg, and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Pick your region, an m5.2xlarge (or larger) instance type, your VPC and subnet, your EC2 key pair, and a security group that allows SSH (22) from your admin network and HTTP (80) from the networks that use the application. Launch the instance.

Step 2: Launch from the AWS CLI

You can also launch the AMI directly. Resolve the product AMI id for your region from the listing, then:

REGION="us-east-1"
AMI_ID="<ami-id>"          # the Infrahub AMI id for your region
KEY_NAME="your-key"
SG_ID="sg-xxxxxxxx"         # allows 22 from your admin CIDR and 80 from your users
SUBNET_ID="subnet-xxxxxxxx"

aws ec2 run-instances \
  --region "$REGION" \
  --image-id "$AMI_ID" \
  --instance-type m5.2xlarge \
  --key-name "$KEY_NAME" \
  --security-group-ids "$SG_ID" \
  --subnet-id "$SUBNET_ID" \
  --associate-public-ip-address \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=30,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=infrahub}]'

The image resolves the instance's own public IP on first boot via EC2 IMDSv2, so the application advertises the correct address with no manual configuration.

Step 3: Retrieve the per-instance credentials

On the first boot of each instance, infrahub-firstboot.service regenerates every secret, initialises empty databases, brings the stack up, verifies the admin login and the API-token round-trip, and writes the credentials to a root-only file. First boot brings up a seven-container stack, so allow a few minutes before the web UI is reachable. Retrieve the credentials over SSH:

sudo cat /root/infrahub-credentials.txt

The file contains the per-instance web URL, the admin username (admin) and password, and the per-instance API token:

infrahub.url=http://<instance-public-ip>/
infrahub.admin.user=admin
infrahub.admin.pass=<INFRAHUB_ADMIN_PASSWORD>
INFRAHUB_ADMIN_PASSWORD=<INFRAHUB_ADMIN_PASSWORD>
INFRAHUB_API_TOKEN=<INFRAHUB_API_TOKEN>

These values are unique to your instance. Store them somewhere safe.

Step 4: Confirm the stack is healthy

Infrahub runs as a Docker Compose stack under infrahub.service. Check the systemd units and the containers:

for s in docker.service infrahub.service; do printf "%-28s %s\n" "$s" "$(systemctl is-active $s)"; done
sudo docker compose --project-directory /opt/infrahub --env-file /opt/infrahub/.env ps \
  --format "table {{.Name}}\t{{.Service}}\t{{.Status}}"

All eight containers should report healthy:

docker.service               active
infrahub.service             active
NAME                         SERVICE           STATUS
infrahub-cache-1             cache             Up 5 minutes (healthy)
infrahub-database-1          database          Up 5 minutes (healthy)
infrahub-infrahub-server-1   infrahub-server   Up 4 minutes (healthy)
infrahub-message-queue-1     message-queue     Up 5 minutes (healthy)
infrahub-task-manager-1      task-manager      Up 5 minutes (healthy)
infrahub-task-manager-db-1   task-manager-db   Up 5 minutes (healthy)
infrahub-task-worker-1       task-worker       Up 4 minutes
infrahub-task-worker-2       task-worker       Up 4 minutes

The application answers on port 80. /api/config confirms the hardened defaults - anonymous access and telemetry are both off:

curl -sS http://localhost/api/config | python3 -c 'import json,sys; m=json.load(sys.stdin)["main"]; print("allow_anonymous_access:", m["allow_anonymous_access"]); print("telemetry_optout:", m["telemetry_optout"])'

allow_anonymous_access: False
telemetry_optout: True

Step 5: Sign in to the web UI

Browse to http://<instance-public-ip>/ and sign in as admin with the password from the credentials file.

After signing in you land on the dashboard, which surfaces open proposed changes, your branches, connected Git repositories, recent activity and the task overview:

Step 6: Explore the schema

Infrahub is schema-driven: every kind of object you store is defined by a schema. Open Object Management to browse the built-in Core schema and to load your own node and generic kinds, each with attributes and relationships that model your infrastructure domain:

You can load a schema from the UI or by posting it to the API. For example, to load a schema definition file:

API_TOKEN="<INFRAHUB_API_TOKEN>"    # from /root/infrahub-credentials.txt
curl -sS -X POST 'http://<instance-public-ip>/api/schema/load?branch=main' \
  -H "X-INFRAHUB-KEY: $API_TOKEN" \
  -H 'Content-Type: application/json' \
  --data-binary @my-schema.json

Step 7: Work with branches and proposed changes

Every change can be made on a branch and reviewed as a proposed change before it merges to main, giving you version control over your infrastructure data. Open Branches to see the default branch and create new ones:

Step 8: Use the GraphQL API

Infrahub exposes a GraphQL API at /graphql. Authenticate with the per-instance API token from the credentials file. For example, count the accounts in the source of truth:

API_TOKEN="<INFRAHUB_API_TOKEN>"    # from /root/infrahub-credentials.txt
curl -sS -X POST 'http://<instance-public-ip>/graphql' \
  -H "X-INFRAHUB-KEY: $API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"query":"query { CoreAccount { count } }"}'

{"data":{"CoreAccount":{"count":2}}}

Security model

This image is secure by default:

• No known credential ships. All seven of upstream's published default secrets are regenerated uniquely for every instance on first boot, before the application serves traffic. The per-instance admin password and API token are written only to /root/infrahub-credentials.txt (mode 0600, root only).
• Anonymous access is disabled. Upstream defaults the object graph to world-readable for unauthenticated callers; this image sets INFRAHUB_ALLOW_ANONYMOUS_ACCESS=false. An unauthenticated request for an authenticated resource is refused:

curl -sS -o /dev/null -w 'anon /api/schema -> HTTP %{http_code}\n' http://localhost/api/schema

anon /api/schema -> HTTP 401

• Only the web UI is exposed. The graph database, PostgreSQL, Redis and RabbitMQ publish no host port and are reachable only on the private container network. Only ports 22 (SSH) and 80 (the web application) are bound off the loopback interface.
• Telemetry off. Product telemetry and analytics are disabled.

Enabling HTTPS

For production use, terminate TLS in front of the instance. The simplest approach on AWS is an Application Load Balancer with an ACM certificate forwarding to the instance on port 80. Alternatively, place a reverse proxy (nginx, Caddy) with a Let's Encrypt certificate for your own domain in front of the application. Point the proxy at http://127.0.0.1:80 and set INFRAHUB_ADDRESS in /opt/infrahub/.env to your HTTPS URL, then restart with sudo systemctl restart infrahub.

Where things live

Support

cloudimg provides 24/7 technical support for this product by email and live chat, with a one-hour average response for critical issues. Our engineers help with deployment, TLS termination, schema design, GraphQL and REST API usage, backups, scaling and upgrades.

• Email: support@cloudimg.co.uk
• Live chat: available 24/7

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.