Architecture

Fabrik runs as a stack of eleven containers: one Django ASGI web process, a Celery worker and scheduler, three event consumers that listen to AWX, a React frontend served by Nginx, and four backing services (PostgreSQL, Neo4j, Redis, RabbitMQ). Nothing in the stack is a single point of unique magic — it's a conventional Django + Celery + Channels application with one twist: Neo4j stores the ACI Managed Information Model so the query builder can reason about class relationships at draw time.

The web tier is stateless. Every long-running thing — query execution, AWX job dispatch, notification delivery, MIM import — is a Celery task. Real-time updates travel over WebSockets through Django Channels, with Redis as the channel layer. AWX status events come in through a dedicated RabbitMQ topic exchange consumed by three small workers.

High-level diagram

The stack at a glance

Services

Eleven containers make up a default deployment:

Data stores

PostgreSQL is the system of record. Every durable object — user accounts, saved queries, scheduled tasks, AWX requests and executions, Time Machine snapshots, audit events — lives here.

Neo4j stores only the ACI MIM metadata. Nodes are Class and Property; edges describe containment, relative-name mappings, and property ownership. The query builder walks this graph to validate connections on the canvas and suggest what classes a given parent can contain.

Redis plays three roles: it's the Celery result backend, the Django Channels channel layer (so a Celery worker can push a WebSocket message to a browser), and a general cache — including the TTL'd MIM query cache.

RabbitMQ is the Celery broker and hosts the awx.events topic exchange. AWX publishes status and output events there (via webhook or a bridge, depending on how you wire AWX); the three event consumers bind to routing keys job.status.*, workflow.status.*, and job.output.*.

Celery queues

The worker listens on seven queues. Each has a narrow purpose so a long AWX run can't starve user-triggered query execution, and vice versa.

Celery beat schedule

Celery beat fires seven recurring tasks:

All schedules are expressed in the server's timezone, controlled by the TZ environment variable.

The event-driven AWX pipeline

Most Ansible Tower integrations poll AWX for job status. Fabrik does too — the awx.sync_running_jobs beat task is a safety net — but the primary path is event-driven.

AWX is configured to publish job events as webhooks. A lightweight bridge forwards those webhooks into the awx.events topic exchange on RabbitMQ, using routing keys that match the event type:

• job.status.* — a job started, succeeded, failed, or was cancelled
• workflow.status.* — a workflow job changed state
• job.output.* — a new chunk of stdout is available

Each routing key is consumed by its own dedicated container (event-consumer-job, event-consumer-workflow, event-consumer-output). The consumer updates the relevant AutomationExecution record, then broadcasts a WebSocket event through the Channels layer so any browser watching that execution sees the change immediately.

If AWX isn't in use, these consumers simply sit idle — no events arrive, no work is done.

WebSocket channels

Daphne terminates WebSocket connections at five paths:

Authentication is checked by middleware before any consumer code runs; the frontend passes a short-lived JWT ticket at connection time.

External systems

Fabrik relies on a small number of systems that live outside the stack. None of them is a container Fabrik ships.

• Cisco APIC — the required one. Every live query goes here. An administrator registers each APIC as a connection; credentials are stored Fernet-encrypted.
• AWX / Ansible Tower — optional. Needed only if you use the Ansible module. Fabrik authenticates with an OAuth token and receives status events through the RabbitMQ pipeline described above.
• SMTP server — optional. Used for notification emails. Bring your own relay; Fabrik does not run one.
• LDAP / Active Directory — optional. The backend image includes the LDAP libraries so you can point Fabrik at a corporate directory for sign-in.

Request lifecycle

It helps to trace one request end-to-end. Suppose you draw a query on the canvas and click Execute:

1. The frontend POSTs the query graph to the backend REST API.
2. The backend validates it, creates a ChainExecution record, and enqueues a task on the query_exec Celery queue via RabbitMQ.
3. A Celery worker picks up the task, resolves the APIC connection, and calls the APIC REST API — one request per node in the chain, possibly in parallel.
4. As each node completes, the worker pushes a progress event through the Channels layer (backed by Redis) to the group chain-execution-<job_id>.
5. Your browser, already connected to ws/chain-execution/<job_id>/, receives each event and updates the canvas in real time.
6. When the final node finishes, the worker persists the result to Postgres, emits one last WebSocket event, and the task ends.

The AWX path looks the same, with two differences: the task runs on the awx_exec queue and calls AWX instead of the APIC, and the status updates arrive through the event-consumer pipeline instead of being emitted by the worker itself.

Deployment topology

A default install runs all eleven containers on a single Docker host. The frontend is the only container you typically expose publicly; everything else binds to the internal Docker network. A reverse proxy (Nginx, Caddy, HAProxy — your choice) sits in front to terminate TLS, route / to the frontend, and forward /api and /ws to the backend.

Horizontal scaling is possible — multiple Celery workers, multiple backends behind a load balancer — but the defaults are sized for a single-host deployment. For install, environment variables, TLS, backups, and upgrades, see the Deployment guide.