Getting Started
From zero to a running Infra UI instance in minutes. This guide walks you through setup and agent management.
Overview
Infra UI is a modern infrastructure management platform built with FastAPI and DDD. It monitors containers, manages access, and orchestrates deployments. The platform includes an optional agent for remote host management and security scanning.
Platform features: Container orchestration, real-time monitoring, security scanning, IAM, multi-tenant isolation, and agent management.
Prerequisites
| Requirement | Version |
|---|---|
| Docker | 24+ |
| Docker Compose | v2+ |
| Python | 3.12+ (for agent) |
| Browser | Modern (Chrome, Firefox, Edge) |
Setup
1. Install
Pull the repository and start all services with Docker Compose:
1git clone https://github.com/infra-ui/repo.git
2cd infra-ui/api_web
3docker compose up -d
2. Configure
Set your environment variables in the .env file:
DATABASE_URL=postgresql://fastapi:fastapi@localhost:5432/infra_ui_db
REDIS_URL=redis://localhost:6379
RABBITMQ_URL=amqp://guest:guest@localhost:5672
SECRET_KEY=change-me-in-production
.wslconfig.3. Launch
Run migrations and start the API server:
1alembic upgrade head
2uvicorn app.main:app --reload --host 0.0.0.0 --port 9000
4. Deploy
Open the dashboard in your browser and start managing your infrastructure:
Navigate to Admin → Agents to register and manage remote agents.
Manage Agents
Infra UI includes an agent management platform for registering, monitoring, and controlling remote hosts. Agents communicate with the API via HTTPS to send heartbeats, receive commands, and report system metrics.
Architecture
Agents run a lightweight process that communicates with the Infra UI API. Each agent authenticates using a registration token and can be managed through the web dashboard or REST API.
┌──────────────────┐ ┌──────────────────┐
│ Agent (remote) │ HTTPS │ Infra UI API │
│ │────────>│ localhost:9000 │
│ - Heartbeat │ │ │
│ - Commands │<────────│ - Register agents│
│ - Metrics │ │ - Assign tasks │
└──────────────────┘ │ - Store data │
└──────────────────┘
Registering an Agent
Agents can be registered through the web UI or directly via the API.
Via the Web UI
-
Go to Admin → Agents
Navigate to
/admin/agentsin the dashboard. -
Click New Agent
Open the creation form from the agents table.
-
Fill in the details
Provide a hostname (unique identifier), display name, OS (linux/windows/macos), architecture (amd64/arm64), and agent version.
-
Create
The agent appears with PENDING status until it connects.
Via the API
1curl -X POST http://localhost:9000/admin/agents \
2 -H "Content-Type: application/x-www-form-urlencoded" \
3 -d "hostname=wsl-ubuntu&os=linux&architecture=amd64&agent_version=1.0.0"
Agent Actions
Agents can be edited or deleted from the agents table in the web UI:
- Edit — Click the pencil icon to open a modal with pre-filled fields (hostname, display name, OS, architecture, version).
- Delete — Click the trash icon and confirm to permanently remove the agent.
Registration Tokens
Tokens are used by agents to authenticate during registration. Generate one via the web UI or API.
Generating a Token
- Navigate to Admin → Tokens (
/admin/agents/tokens). - Click Generate Token.
- Set the expiration date in the modal (default: 1 hour).
- Click Generate and copy the token — it's shown only once.
Tokens can be deleted from the table using the Delete button (visible on all tokens regardless of status).
Using a Token (Agent-Side)
1curl -X POST http://localhost:9000/api/v1/agents/register \
2 -H "Content-Type: application/json" \
3 -d '{
4 "hostname": "wsl-ubuntu",
5 "token": "<your-registration-token>",
6 "os": "linux",
7 "architecture": "amd64",
8 "agent_version": "1.0.0"
9 }'
Agent Status
| Status | Meaning |
|---|---|
| PENDING | Registered but never connected |
| ONLINE | Connected and sending heartbeats |
| OFFLINE | Was online, but missed heartbeat window |
Sending Commands
Commands can be sent to agents through the web UI or the REST API.
Via the Web UI
- Go to Admin → Agents.
- Click the Terminal icon on an agent row.
- View command history and results.
Via the API
1# Send a command to an agent
2curl -X POST http://localhost:9000/api/agents/<agent_id>/commands \
3 -H "Content-Type: application/json" \
4 -d '{"command": "uname -a"}'
Agent Daemon (Transport Layer)
The infra-agent includes a transport layer that runs as a background daemon, continuously communicating with the Infra UI API.
Daemon Flow
-
Read config
The agent reads its configuration (token, API URL, intervals).
-
Register
Calls
POST /api/v1/agents/registerwith the token → receivesagent_idand server configuration. -
Start background loops
Three concurrent loops run: Heartbeat (every 30s), Container report (every 60s, if Docker SDK installed), Command poll (every 15s).
Running as a Daemon
1# Set token and start
2AGENT_REGISTRATION_TOKEN="AGT_xxx" python -m agent --daemon
3# Or via config file
4cat > agent.yaml << EOF
api_url: "http://localhost:9000"
registration_token: "AGT_xxx"
heartbeat_interval: 30
container_report_interval: 60
command_poll_interval: 15
EOF
5python -m agent --daemon -c agent.yaml
Config Options (Environment Variables or YAML)
| Variable | Default | Description |
|---|---|---|
AGENT_API_URL | http://localhost:9000 | Infra UI API base URL |
AGENT_REGISTRATION_TOKEN | "" | Token for agent registration |
AGENT_HEARTBEAT_INTERVAL | 30 | Heartbeat interval in seconds |
AGENT_CONTAINER_REPORT_INTERVAL | 60 | Container report interval in seconds |
AGENT_COMMAND_POLL_INTERVAL | 15 | Command poll interval in seconds |
The agent also reads heartbeat from the server's registration response, overriding the local config value.
IAM & RBAC
Infra UI provides two layers of access control: coarse-grained identity roles and granular resource-level RBAC permissions.
Overview
| Layer | Module | Purpose |
|---|---|---|
| Identity Role | Identity | Coarse-grained user level (admin, editor, user, metrics) |
| IAM Roles & Permissions | IAM | Granular resource-level RBAC (resource:action pairs) |
(admin, editor, user, metrics) — bypasses all IAM checks when set to admin. IAM Permissions = what you can do (container:create, monitoring:read, etc.) — evaluated for non-admin users.Roles vs Groups
IAM Role
An IAM Role is a template of permissions. It defines what actions are allowed on which resources.
| Field | Description |
|---|---|
name | Role name (e.g. "container-manager", "viewer") |
description | Human-readable description |
is_default | true for system roles (admin, editor, user, metrics), false for custom RBAC roles |
permissions | List of Permission objects (resource:action pairs) |
System roles are seeded automatically: admin, editor, user, metrics. Custom RBAC roles are created via the IAM UI for fine-grained control.
Group
A Group is a tenant-scoped container that bundles IAM roles together and assigns them to users.
| Field | Description |
|---|---|
name | Group name (e.g. "devops-team", "readonly-auditors") |
description | Human-readable description |
tenant_id | Tenant this group belongs to (from the tenant switcher) |
roles | List of IAM Roles assigned to this group |
The relationship flows as:
User → Group → Roles → Permissions
- Create Permissions — e.g.
container:create,monitoring:read - Create an IAM Role — attach permissions (e.g. "Container Manager" gets
container:create,container:read,container:update) - Create a Group — attach IAM roles (e.g. "DevOps Team" gets the "Container Manager" role)
- Assign users to the Group — they inherit all permissions from the group's roles
Permission Model
Each Permission is a pair of Resource × Action.
Resources
| Value | Description |
|---|---|
tenant | Tenant settings and configuration |
application | Application catalog |
security | Security monitoring |
container | Container management |
monitoring | Metrics and monitoring |
audit | Audit logs |
notification | Notifications |
user | User management |
role | Role management |
group | Group management |
api_token | API token management |
settings | System settings |
* | All resources (wildcard) |
Actions
| Value | Description |
|---|---|
create | Create new resources |
read | View/read resources |
update | Modify existing resources |
delete | Remove resources |
manage | Full management (all CRUD) |
scan | Scan/inspect resources |
approve | Approve changes |
export | Export data |
import | Import data |
assign | Assign resources to users/groups |
* | All actions (wildcard) |
Examples
| Permission | Means |
|---|---|
container:create | Can create containers |
monitoring:read | Can view monitoring data |
user:* | Full control over users |
*:read | Can read anything |
*:* | Full access to everything |
Assigning Permissions to a Role
Via the IAM Web UI
- Go to IAM & RBAC in the sidebar
- Click the Permissions tab → New Permission — fill in name, resource (dropdown: container, monitoring, tenant, etc., or
*for all), action (create, read, update, delete, manage, or*) - Click the Roles tab → New Role — fill in name and description
- Use the API to attach permissions to the role
Via the API
1# List available permissions
2GET /iam/permissions
3# Create a role with permissions
4POST /iam/roles
5{
6 "name": "container-manager",
7 "description": "Can manage containers",
8 "is_default": false,
9 "permission_ids": ["uuid-of-container:create", "uuid-of-container:read"]
10}
11# Update a role's permissions
12PUT /iam/roles/{role_id}
13{
14 "permission_ids": ["uuid-of-perm1", "uuid-of-perm2"]
15}
Tenant Isolation
Groups are scoped to a tenant. When you select a tenant via the tenant switcher and go to IAM & RBAC → Groups, any group you create is automatically assigned to that tenant.
Roles and Permissions are global (shared across all tenants). The same "Container Manager" role can be used in multiple tenants' groups.
Quick Reference — Creating a User
- Go to Users page (
/admin→ Users section) - Click New User
- Fill in email, password
- Select an Identity Role (
admin/editor/user/metrics) - The user can now log in with that base access level
- For finer control, create IAM groups and add the user via the API:
1POST /iam/groups/{group_id}/members 2{ "user_id": 123 }