Architecture

The formae architecture differentiates itself from traditional tooling through:

1. Active components that automate processes typically requiring manual intervention, reducing operational burden on users.

2. Automatic state management that tracks all infrastructure changes regardless their origin, while maintaining the state so that an always up-to-date Infrastructure as Code representation is available upon request at any time.

These few design principles enable improved system maintainability, change tracking, and operational efficiency throughout the infrastructure lifecycle while directly addressing the limitations and inefficiencies of legacy tooling approaches.

CLI and API

The CLI and API components form the frontend of the system, providing a consistent interface for users and applications to interact with the platform. The API currently lives in the agent, and will be extracted into a separate component in the future. CLI can operate on your local machine, or on a node in your CI/CD system.

Metastructure

The formae platform uses a concept called Metastructure - an internal representation that combines your infrastructure configuration with operational logic. This enables:

• Active monitoring of infrastructure changes in real-time
• Asynchronous application of changes that converge to your desired state
• Complete versioning history, allowing you to take any infrastructure state (past or present), modify it, and apply it to any environment
• Automatic tracking of changes made both inside and outside of formae

Unlike traditional IaC tools that only store static configuration, Metastructure maintains both the what (your infrastructure) and the how (the operations needed to manage it), enabling formae to continuously sync your actual infrastructure with your code. This design moves complexity into the agent, while keeping technology plugins simple.

Agent

The Agent is the actively running backend component of the formae platform, responsible for executing core system operations. Currently, the platform supports single-agent operation, with multi-agent distribution planned for future releases.

Key characteristics of the Agent include:

• Central execution engine for platform operations
• Maintains state and handles resource management
• Processes requests from the CLI (through API)
• Manages the metastructure implementation

The formae Agent can be deployed in different ways, for example:

1. Cloud Deployment - Deploying a formae Agent into a cloud account as a service is the standard approach for production environments.

2. Local Operation - The service can also be fully operated on a local computer, whether on a developer's machine or a CI/CD node.

3. Container or k8s Operation - The formae Agent can run in a container, and in a k8s pod with additional prerequisites, such as storage.

The agent manages the lifecycle of technology plugins that are shipped together with formae, and those implemented for customization of infrastructure. These plugins are always executed as separate processes, and are never embedded.

Important: Single agent per target

A single target must only be managed by one formae agent. Multiple agents managing overlapping targets will cause conflicts: each agent operates with its own datastore, leading to conflicting discovery, duplicate resource tracking, and unpredictable behavior.

The correct pattern: One agent per target. Multiple team members connect their CLIs to the same agent, ensuring a single source of truth.

When designing targets across agents: Ensure targets managed by different agents don't overlap. Each piece of infrastructure must be managed by exactly one agent.

Datastore

The Agent utilizes a datastore for persistence. The datastore implementation can vary depending on deployment requirements:

• SQLite - the default datastore option, suitable for both local and production deployments
• Postgres - alternative datastore rather suited for production deployments
• Additional datastore implementations planned for future releases