[On-Demand – Webinar] Fractal Sprint on Digital Sovereignty | Watch now →

Fractal Cloud
Blog
Fractal Cloud interface showing how to create a Fractal and build reusable infrastructure

How to Create a Fractal: A Technical Guide to Building Reusable Infrastructure

Introduction

Your developers need an environment. They open a ticket. They wait. Days pass. Someone manually provisions the resources, wires them together, checks compliance, and closes the ticket. Next week, someone else needs the same thing and the cycle repeats.This is what happens when infrastructure knowledge lives in people's heads instead of in the platform. Fractals are how you fix that.In this post, you'll learn what a Fractal actually is at a technical level, how the component model works under the hood, and how to create one step by step. This is aimed at platform engineers and DevOps architects who want to go beyond the concept and start building.If you're looking for a higher-level overview of why platform engineering matters, check outPlatform Engineering 2026: Beyond the Portal. Here, we go hands-on.

What Is a Fractal, Technically?

A Fractal is composed of two entities:🔷 Blueprint: a versioned group of components and integrations that define the infrastructural foundation of a compliant system.🔷 Interface: a versioned set of operations through which the Fractal can be further specialized or extended (adding, removing, or modifying components and their integrations).When a developer instantiates a Fractal, the result is a Live System, a real, provisioned environment that stays synchronized with the declared intent specified by the Fractal.The key property: any operation on a compliant Fractal produces either a compliant Live System or a further specialized Fractal. You can't break governance.The Fractal Automation Engine continuously monitors the Live System, detects drift, and reconciles it back to the desired state.This is fundamentally different from traditional IaC templates. A Terraform module produces a state file and hopes nothing changes. A Fractal produces a Live System that is actively governed for its entire lifecycle.

The Component Model: Component → Service → Offer

Before building a Fractal, you need to understand the three-level component hierarchy. This is the abstraction layer that makes Fractals cloud-agnostic.ComponentAn infrastructure capability, uniquely identified by an Infrastructure Domain and a Name. It is vendor-agnostic and delivery-model-agnostic. It describes [b]what[b] is needed, not how or where.Each Component defines:🔷 Parameters: what can be configured🔷 Dependencies: what other components are required🔷 Links: how other components connect to itExample: 'Compute.ContainerOrchestrator' means "I need container orchestration."ServiceA specialization of a Component that adds a Service Delivery Model (IaaS, CaaS, PaaS, FaaS, SaaS).Example: 'Compute.PaaS.Kubernetes' means "I need a specific container orchestrator, Kubernetes, delivered as a managed platform."OfferA concrete, vendor-specific implementation that fulfills a Service. This is the actual resource provisioned on a specific cloud provider.Example: 'Compute.PaaS.AKS' means "Azure Kubernetes Service."The full resolution path looks like this:The same Fractal definition deploys AKS on Azure, EKS on AWS, or OpenShift on-premises without changing the Fractal definition. The resolution happens at instantiation time based on the target environment.

The Composition Hierarchy: Atom → Molecule → Fractal

Components are composed into increasingly complex structures using a three-level hierarchy.AtomThe smallest, indivisible unit ofinfrastructure. An Atom wraps a raw cloud resource with everything needed to make it production-ready: security hardening, monitoring hooks, backup policies, compliance tags.An Atom is not a raw cloud resource. A raw EC2 instance is a resource. An Atom wraps it with your organization's standards so every instance starts with the right configuration, the right policies, the right monitoring.Examples: a Kubernetes cluster, a PostgreSQL database, a Kafka broker.MoleculeA composed group of Atoms connected by Links. Represents a functional building block.Example: a "web tier" Molecule = Kubernetes cluster + load balancer + API gateway, all wired together.FractalA complete, deployable architecture pattern composed of Atoms and Molecules. Represents a full infrastructure stack: compute, storage, networking, messaging, observability; all defined, connected, and governed.The hierarchy is recursive a Fractal can contain other Fractals:

Links: How Components Connect

A Link is a connection between two components that carries semantic meaning. It's not just "these two things are connected" it specifies how they interact.Links include parameters, based on the components they connect:🔷 A Storage link between a compute component and a storage component specifies access mode (read, write, readWrite), data format (JSON, Parquet, Avro), consistency level;🔷 A Messaging link between a compute component and a broker component specifies role (producer, consumer), delivery semantics (at-most-once, at-least-once, exactly-once), consumer group🔷 A Network link between IaaS components specifies protocol (HTTP, gRPC, TCP), routes, authentication requirementsWhen a Fractal is deployed, the Fractal Automation Engine auto-configures all connections between components: security groups, IAM roles, connection strings, certificates. Developers don't wire anything manually.

Building a Fractal: The Three Phases

Creating a Fractal follows a clear three-phase model that maps to organizational roles. Let's walk through this using a concrete example: a 3-tier application with Kubernetes, PostgreSQL, and a web application workload.Prerequisites: Security & Governance FoundationBefore any Fractal exists, the Ops team sets up the governance boundaries.Step 1: Create a Resource Group. This is the logical governance boundary. Teams, users, and permissions are all managed at this level.Step 2: Initialize the Environment. This connects a cloud environment to the Fractal Cloud control plane by installing a Cloud Agent.The Cloud Agent is a lightweight process deployed inside your cloud environment (AWS account, Azure subscription, GCP project). It works on a pull-based model:1. The agent polls the control plane: "What should my environment look like?"2. The control plane responds with the desired state3. The agent reads the actual state from infrastructure APIs4. The agent diffs desired vs. actual5. The agent reconciles: creating, updating, or removing resources6. The agent reports status back to the control planeThis pull-based architecture means no inbound firewall rules, no VPN, no stored credentials on the control plane. The agent uses local IAM roles and communicates outbound over HTTPS only.Phase A: Platform Engineer: Define the FractalThis is where you build the reusable construct.Step 1: Define the Blueprint. Choose which components make up your architecture. For a 3-tier app:🔷 'Compute.PaaS.Kubernetes' the compute layer🔷 'Storage.PaaS.PostgreSQL' the data layer🔷'CustomWorkloads.CaaS.KubernetesWorkload' the application workloadStep 2: Configure each component. Set the parameters that represent your organization's standards. For the Kubernetes cluster, this might include node pool sizes, IP ranges, autoscaling policies. For PostgreSQL, the schema, charset, and backup configuration.Step 3: Define Links between components. Wire the workload to the Kubernetes cluster (compute link) and to PostgreSQL (storage link with access mode and connection properties).Step 4: Define the Interface. Specify which parameters developers can configure when they instantiate this Fractal, and which operations are allowed on the resulting Live System. The Interface is what developers see everything else is abstracted away.Step 5: Version and publish. The Fractal is now available in the catalog.Phase B: Developer and/or Platform Engineer Instantiate the FractalDepending on how much freedom the organization wants to give the devs, these steps can be performed by either the platform engineer or the developer.The developer's workflow is minimal:1. Browse the Fractal catalog and select the 3-tier application Fractal2. Provide the required parameters: environment name, application repo, branch, runtime variables3. Request instantiation (via Web UI, SDK, or API) with selection of the target infrastructure: hyperscaler, regional cloud provider or on-prem.4. The Fractal Automation Engine validates, deploys, and wires everything together5. A Live System is created, complete, governed, and continuously managedNo IaC to write. No cloud console access needed. No ticket to open.

Two Approaches: Live-System First vs. Fractal First

Fractal Cloud supports two deployment strategies, depending on your maturity and goals.Live-System First focus on the end system for quick roll-outs. Best for PoCs and experimental projects. You describe your desired infrastructure state using pre-hardened components, and later extract a reusable Blueprint from the running Live System.Fractal First focus on reusability and governance from the start. Best for establishing a cloud adoption framework at enterprise level. You define Blueprints and Interfaces upfront, and teams instantiate them without needing cloud environment access.For most organizations starting out, the advice is: start Live-System First with a concrete use case, validate the model, then extract a Fractal and scale from there.

SDK Integration

Fractals can be defined and managed programmatically using the SDK. This is the path for teams that want Fractals-as-code versioned in Git, tested in CI, deployed in pipelines.Available SDKs:🔷 Java SDK ('fractal-java-sdk')🔷 TypeScript SDK ('fractal-ts-sdk')🔷 Terraform Provider ('terraform-provider')🔷 REST API for integrating with existing enterprise toolsSDK authentication uses service accounts stored in cloud-native secret stores (Azure Key Vault, AWS Secrets Manager, GCP Secret Manager). Secret naming is consistent across all providers, so the SDK experience is unified regardless of the target cloud.The typical SDK workflow for a platform engineer:1. Authenticate with the management environment2. Define the Fractal programmatically: components, links, parameters3. Publish the Fractal to the catalog4. Developers instantiate it via SDK calls, API, or pipeline triggers

Why This Matters

The difference between a Fractal and a traditional IaC template comes down to three things.Lifecycle. A Terraform module runs and produces a state file. A Fractal produces a Live System that is continuously monitored, drift-corrected, and governed. Infrastructure doesn't exist in a vacuum it changes, and the platform has to account for that.Abstraction. Developers don't write IaC. They don't need to know about VPCs, security groups, or IAM policies. They consume a governed construct that encodes the expertise of the platform team.Scalability. A Fractal defined once can be instantiated thousands of times across multiple clouds. Updates to the Blueprint propagate to all derived Live Systems. The platform team's impact scales without their workload scaling.

Wrapping Up

A Fractal is not a template. It's a governed, versioned, composable infrastructure construct that encodes your organization's expertise into a reusable asset.Key takeaways:🔷 The Component → Service → Offer model makes Fractals cloud-agnostic at the definition level while fully leveraging provider-specific services at the implementation level🔷 The Atom → Molecule → Fractal hierarchy lets you compose infrastructure from hardened building blocks🔷 Links carry semantic meaning the platform auto-configures connections, security, and credentials🔷 The pull-based Cloud Agent architecture means zero inbound firewall rules and continuous drift reconciliation🔷 Two approaches: Live-System First for quick wins, Fractal First for enterprise-scale governanceReady to build your first Fractal?Check out the docs and start with the guided tutorial.Build Faster, Run Anywhere.

Cut the Wait. Reduce the Cost.Keep Control.

Get StartedBook a Demo

More articles

Illustration of Fractal Cloud orchestrating infrastructure components, highlighting how internal platforms can become bottlenecks

When Internal Platforms Become Bottlenecks

Over the last decade, many organizations have embraced Platform Engineering as a way to accelerate software delivery.The promise is compelling: build an internal platform that provides developers with standardized tools, infrastructure, and automation so they can focus on building applications instead of managing environments.In theory, this should increase productivity, improve governance, and reduce operational overhead.In practice, things are often more complicated.

Simplifying NIS2 compliance in multi-cloud environments through standardized infrastructure and automation

NIS2 and Cloud: how to simplify compliance without slowing down development

🔹 Executive takeawayNIS2 compliance is a matter of operational scale, not just regulation.Manual approaches are not sustainable in multi-cloud environments.Standardizing infrastructure is the most effective way to reduce risk and complexity.Embedding compliance into the platform allows you to accelerate without losing control.The NIS2 directive introduces new cybersecurity requirements for European organizations.The problem in 2026 is not understanding them.It’s implementing them in complex cloud environments without increasing operational complexity or slowing down development.Fractal Cloud addresses this challenge by integrating security, governance, and automation directly into the infrastructure.

Fractal Cloud Security by Design with built-in compliance in every Fractal

Security by Design: How Every Fractal Comes With Compliance Built In

There's a pattern in engineering organizations that have grown fast. Security works like this: developers provision infrastructure, then a security review happens, then issues get filed, then someone fixes them, then another review. The loop takes days. Sometimes weeks.This isn't security. It's security theater with a delayed blast radius.The deeper problem: when security lives in the process around infrastructure, it can't keep pace with the infrastructure itself. Every new team, every new cloud account, every new environment is another opportunity for the process to break down.This post is for platform teams and DevOps engineers who are tired of security being a bottleneck rather than a baseline. We'll cover why bolt-on security doesn't scale, what "security by design" means at the infrastructure level, and how Fractal Cloud implements it.