Skip to main content

Why Fractal Cloud

Your infrastructure already works. You have engineers, you have processes, you have deployments running in production. The question isn't whether you can manage infrastructure — it's whether you should keep spending time on problems that have already been solved.

Fractal Cloud encodes your infrastructure standards into reusable building blocks and gets out of the way when you want it to. It doesn't replace your team — it gives them leverage.

This page addresses the most common concerns we hear from engineering teams evaluating the platform.

"We're not a large enterprise — we don't need this"​

You don't need to be large to benefit from standardization. If you have two engineers deploying to one AWS account, Fractal Cloud ensures that every VPC, every Kubernetes cluster, and every database follows the same configuration — without anyone having to remember which settings to use.

Mid-size teams benefit the most because they don't have the headcount to build an internal developer platform. Fractal Cloud gives you one off the shelf:

  • No platform team required. Your existing engineers define Fractals (infrastructure blueprints) that encode your standards. New deployments use those Fractals directly — no tickets, no waiting.
  • Start small. Deploy a single VPC. Add a Kubernetes cluster when you need one. Compose them into a full architecture when you're ready. You're not buying a monolith — you're adopting building blocks at your own pace.
  • Grow without rebuilding. The same Fractal that serves your team of 5 works when you're a team of 50. Governance, compliance, and drift detection come built in — you don't bolt them on later.

"We only use one cloud — isn't this for multi-cloud?"​

Multi-cloud is a capability, not a requirement. Single-cloud teams benefit from Fractal Cloud in a different way: consistency.

Every cloud provider has hundreds of services, each with dozens of configuration options. Even within one cloud, it's easy for teams to deploy resources in subtly different ways — different networking patterns, different security group rules, different naming conventions. Over time, this drift creates operational risk.

Fractal Cloud solves this by letting your senior engineers encode the right way to deploy on your cloud into reusable Fractals. Every deployment follows the same pattern, every time:

  • Standardized networking. Hub-and-spoke topology, CIDR allocation, security groups — defined once, applied everywhere.
  • Compliant by default. If your Fractal includes encryption, logging, and access controls, every deployment inherits them automatically.
  • Portable if you need it later. If your strategy changes and you adopt a second cloud, your Fractals adapt. The abstract Components in your blueprints resolve to vendor-specific Offers for whichever cloud you target. No rewrite needed.

"We'll lose control of our infrastructure"​

This is the most important concern, and we take it seriously. Fractal Cloud is designed with multiple layers of control that ensure you are always in charge.

You declare, the agent executes​

Fractal Cloud uses a declarative model. You declare what you want — a VPC with these subnets, a Kubernetes cluster with this configuration, a PostgreSQL database with these parameters. The Cloud Agent provisions exactly that. Nothing more, nothing less. The agent doesn't make decisions about your infrastructure — you do.

Break-the-glass: instant manual override​

Every resource managed by Fractal Cloud carries a managed-by: fractal-cloud tag. Remove the tag, and the agent immediately stops managing that resource. No approval process, no timeout, no waiting. You're back in full manual control.

  • Per-resource granularity. Override one resource without affecting others.
  • No time limit. A resource can stay in manual override indefinitely.
  • Re-adopt when ready. Add the tag back, and the agent resumes reconciliation to your declared state.
  • Non-negotiable safety guarantee. The agent never restores a removed tag. Only you can add it back.

Read the full protocol: Break-the-Glass

Pull-based architecture: you control the connection​

The Cloud Agent runs inside your environment and initiates all communication. The Control Plane never pushes to the agent, never opens inbound connections, and never holds your cloud credentials. If you want to stop all Fractal Cloud activity, stop the agent. Your infrastructure continues running.

Environment deletion: clean exit, running infrastructure​

Delete an environment from Fractal Cloud, and all Cloud Agent resources (the agent itself, its IAM roles, its networking) are removed from your cloud account. Your live systems — VPCs, clusters, databases, workloads — continue running untouched. They're your infrastructure, not ours.

Read the details: Environment Deletion

"We don't want another lock-in"​

Neither do we. Our goal is to help you remove existing lock-in — to cloud providers, to tribal knowledge, to manual processes — without replacing it with lock-in to us.

We want you to remove lock-in without adding a new one.

Here's how we back that up:

Terraform extraction​

Export any Fractal definition as Terraform HCL. Your infrastructure is described in industry-standard Infrastructure as Code that any engineer can read, modify, and apply independently of Fractal Cloud.

Read the guide: Terraform Extraction

Environment deletion​

Remove an environment from Fractal Cloud. The agent and its resources are cleaned up. Your infrastructure keeps running. You own it entirely. There is no "Fractal Cloud runtime" embedded in your resources — they're standard cloud resources with standard configurations.

Open standards​

Fractal Cloud deploys standard cloud resources using standard cloud APIs. Your Kubernetes clusters are real Kubernetes clusters. Your PostgreSQL databases are real PostgreSQL databases. Your VPCs are real VPCs. If you walk away from Fractal Cloud, you're left with the same infrastructure any cloud engineer would recognize and manage.

Break-the-glass at scale​

Remove the managed-by tag from all your resources. The agent stops managing everything. Your entire infrastructure portfolio becomes manually managed. No degradation, no dependencies, no orphaned state.

"It's too much automation — we don't need this huge monster"​

Fractal Cloud is not all-or-nothing. You choose the scope:

  1. Start with one Atom. An Atom is the smallest unit — a single infrastructure component with embedded best practices. Deploy one VPC. That's it. Fractal Cloud manages that VPC, detects drift, and keeps it compliant. Everything else stays as-is.

  2. Add a second Atom. Deploy a managed Kubernetes cluster. Now you have two components managed by Fractal Cloud. The rest of your infrastructure is untouched.

  3. Compose when ready. When you see the pattern, combine your Atoms into a Molecule (a functional building block), then into a Fractal (a complete architecture). This happens at your pace, not ours.

  4. Mix managed and unmanaged. Some resources managed by Fractal Cloud, others managed manually or by Terraform. They coexist in the same cloud account. Fractal Cloud only touches resources it created and tagged.

The platform is designed to be adopted incrementally. There is no minimum scope, no required migration, and no "all infrastructure must go through Fractal Cloud" prerequisite.

Next steps​

  • Quick Start — deploy your first resource in minutes
  • Architecture — understand how the Control Plane and Cloud Agents work
  • Break-the-Glass — see the manual override protocol in detail