Get Started withFractal Cloud

Yes. Fractal modules are cloud-agnostic and deployable to multiple providers without rewriting. Multi-cloud support is built in.

Yes. Fractal Cloud deploys into your cloud accounts using lightweight in-account agents. You retain full control and visibility.

Yes. Fractal Cloud supports deploying Kubernetes-based workloads and will support more runtime types. You can integrate these into Fractals or add them post-deployment.

Yes. Every Live System is versioned, traceable, and visible in a central UI. Access and state changes are logged.

No. Infrastructure, Operations, and Development teams use abstracted modules and APIs. There’s no need to learn each cloud provider’s CLI, templates, or IaC specifics

Yes. Modules are built with best practices from frameworks like Azure CAF and AWS Well-Architected. Policies and guardrails are enforced automatically.

Yes. Developers can deploy and manage infrastructure using the web UI or SDK, within limits set by platform governance.

The platform detects configuration drift and allows safe updates using the Automation Engine, which applies changes within maintenance windows.

The Fractal Automation Engine runs as SaaS by default. A dedicated option is available for enterprises that require data residency or full isolation.

The Java SDK can be embedded into programs that you can run inside pipelines, services or full-blown applications, enabling full infrastructure automation as part of your delivery process.

- Up to 30% infrastructure cost savings → Fractal optimizes cloud usage and automates provisioning, reducing over-provisioning and idle costs.- 70% reduction in specialized resources needed → Teams don’t need to master cloud internals or write IaC scripts, Fractal handles it through ready-made modules.- 10× less code written for infrastructure → Developers work with concise, high-level SDK commands instead of thousands of lines of infrastructure code.- Built-in cloud compliance and governance → Security and policies are enforced automatically, so environments stay compliant without manual checks.- Day-one multi-cloud capability → The same Fractal can run on AWS, Azure, GCP, or OCI without refactoring or duplicating effort.

A Fractal is a reusable, governed, cloud-agnostic infrastructure construct that encapsulates both a Blueprint (the composition of components and their connections) and an Interface (the operations developers can perform). While a Fractal includes a blueprint as part of its structure, it goes beyond static definitions by enabling dynamic lifecycle actions. Developers can instantiate Fractals into Live SystemsThe running systems created from Fractal Cloud patterns. A Live System is the real cloud deployment that application teams use, operate and evolve. on demand.

Fractal Cloud is a platform engineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. solution that delivers secure, compliant infrastructure across any cloud. It gives developers ready-to-use building blocks and architecture templates, combining vendor-specific knowledge, security best practices, and automation by design. It removes the need for deep cloud specialization or costly custom development, while allowing operations teams to maintain control through centralized automation and governance.

Monitoring & Response provides ongoing monitoring, incident detection, and automated response for infrastructure managed by Fractal Cloud. It ensures your Live SystemsThe running systems created from Fractal Cloud patterns. A Live System is the real cloud deployment that application teams use, operate and evolve. remain healthy and resilient, with active support for business continuity and disaster recovery. It also includes alert routing and system reconciliation features.

Onboarding & Adoption helps teams adopt Fractal Cloud by guiding them through initial setup, environment creation, blueprint integration, and CI/CD embedding. It also includes access to onboarding resources, templates, and hands-on collaboration with Fractal experts.

Tech Support handles troubleshooting and resolution for issues related to platform usage, SDK behavior, or infrastructure deployment. It includes structured triage workflows and SLA-backed response times.

It’s the orchestration layer that interprets Fractals, performs deployment, enforces policies, and monitors drift. It runs as a SaaS service or in private mode.

Fractal Cloud eliminates the need for handwritten IaC scripts by offering a Java SDK and pre-approved, composable modules maintained by platform teams. This enables faster, more consistent, and governed infrastructure delivery without relying on low-level scripting.

Currently Java. C# support is in development.

The following services are bundled with the Enterprise version and can also be added to Workgroup accounts based on specific needs:- Fractal Automation Engine- Dev Support (Onboarding and Adoption)- Ops Support (Monitoring and Response)- Tech Support (Issue Resolution)

A Live System is the running instance of a Fractal, deployed infrastructure on your cloud account that remains continuously governed and in sync with your policies. One Fractal can be instantiated multiple times, generarting multiple self-similar Live SystemsThe running systems created from Fractal Cloud patterns. A Live System is the real cloud deployment that application teams use, operate and evolve..

Platform teams (e.g., CCoE) use it to build, approve, and publish Fractals. Application teams use it to deploy infrastructure. Operations teams use it to monitor and manage environments.

It means developers can launch production-grade infrastructure with minimal code, and deploy it consistently across AWS, Azure, GCP, or OCI, without having to learn each cloud’s tools and practices.

An Atom is a single hardened resource, for example a Kubernetes cluster or a database, already configured to production standards. A Molecule connects several Atoms into a functional unit through typed links: a web tier made of a cluster, a load balancer and an API gateway wired together, with the security groups and routing implied by those connections configured automatically. A Fractal assembles Atoms and Molecules into a complete deployable architecture. The hierarchy is recursive, so a Fractal can contain other Fractals, and a rule attached to an Atom applies to every system built from it. If the Kubernetes Atom requires pod security admission, every system containing that cluster has it, by construction rather than by review.

An operating model defines how platform teams and development teams collaborate, how responsibilities are shared, and how infrastructure is delivered and governed. A well designed operating model reduces manual handoffs, standardizes workflows, and enables developers to provision infrastructure independently while maintaining security and compliance.

Development teams are measured by delivery speed, while operations teams are responsible for security, stability, compliance, and cost control. Without a shared operating model, these objectives often conflict, leading to manual approvals, ticket based processes, and increased delivery friction.

Treating infrastructure as a product means designing reusable, versioned, and continuously maintained infrastructure capabilities that development teams can consume independently. This approach improves consistency, reduces operational bottlenecks, and allows platform teams to evolve standards centrally instead of supporting every request individually.

Provisioning creates an infrastructure environment only once, while Day 2 Operations cover everything that happens afterward, including updates, security patches, compliance, configuration management, and lifecycle governance. The long term success of a platform depends on how well it manages infrastructure throughout its lifecycle, not just how quickly it provisions new environments.

Autonomous infrastructure remediation is the ability to detect that a system has diverged from its intended state and correct it without a person executing the change. In practice there are two levels. The first is reconciliation: the intended state is declared, the difference is detected, and the environment is brought back in line. The second is deciding what to do about a problem that is not a simple divergence, and there the decision has to come from somewhere: a rule, an operator, or an external analysis system. The two are often described together, which hides the fact that only the first is a closed loop.

Observability helps organizations detect and understand infrastructure issues by collecting metrics, logs, and traces. Remediation goes one step further by executing the actions required to resolve those issues. Together, they enable faster and more reliable operational responses.

Deterministic automation executes only predefined and approved operations based on explicit rules rather than probabilistic decisions. This makes automated remediation predictable, explainable, and fully auditable, which is essential in regulated and mission critical environments.

Because the action space is defined in advance. A Fractal declares which lifecycle operations are allowed on a system, and nothing outside that set can be executed, whoever or whatever requests it. Fractal Cloud continuously reconciles each Live System against its declared state. When a remediation decision comes from outside, for example from a monitoring or analysis platform, Fractal Cloud acts as the actuator and executes it inside the same boundaries. Every action is recorded against the Fractal that authorized it.

A Digital Twin of the Organization (DTO) is a live model of an IT estate that represents not only the individual systems but the relationships between them. Traditional monitoring tells you that a component is failing. A DTO tells you what else depends on that component, so an event can be assessed by impact rather than by alert volume. It is a category of observability and analysis product rather than an infrastructure platform: the model produces a decision, and something else has to carry it out.

Composable infrastructure is an architectural approach where complex environments are assembled from reusable, standardized building blocks rather than created as unique implementations. Each component has a well defined purpose and can be combined with others according to predefined rules, making infrastructure easier to scale, govern, and evolve over time.

Composable architecture allows platform teams to standardize infrastructure without increasing operational complexity. Instead of maintaining many independent templates or scripts, teams build reusable components that can be assembled into complete infrastructure patternsRepeatable combinations of compute, storage, network, observability and security capabilities. Fractal Cloud turns these patterns into reusable assets that can be shared across teams., reducing duplication, simplifying governance, and improving consistency across environments.

Infrastructure as Code templates typically describe complete infrastructure deployments for specific scenarios. Reusable infrastructure components represent individual capabilities that can be composed into multiple architectures, making infrastructure easier to standardize, evolve, and govern without maintaining numerous independent templates.

Composable infrastructure reduces complexity by assembling new systems from standardized, governed components. Reusing the same architectural building blocks across projects limits duplication, improves consistency, and enables infrastructure to evolve without creating new implementations for every project.

Internal Developer Platforms become bottlenecks when they centralize too much operational responsibility, rely on rigid frameworks, or require manual intervention for routine requests. Instead of reducing complexity, they create new dependencies that slow both platform teams and developers.

Common Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. anti patterns include building proprietary platforms that are difficult to evolve, duplicating infrastructure automation across repositories, treating infrastructure as isolated scripts instead of reusable standards, and relying on manual processes for routine platform operations.

Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. scales more effectively when infrastructure knowledge is captured as reusable architectural patterns rather than custom tools or duplicated automation. This allows platform teams to evolve standards centrally while enabling development teams to provision infrastructure consistently and independently.

Modern software systems are inherently complex. Rather than hiding that complexity behind rigid tools, successful platforms organize it into reusable architectural building blocks that encapsulate infrastructure expertise, governance, and operational best practices while remaining flexible enough to evolve.

NIS2 compliance is the process of meeting the cybersecurity, risk management, and governance requirements defined by the European Union's NIS2 Directive. It requires organizations to implement appropriate technical and organizational measures to protect critical systems, manage cyber risks, and demonstrate compliance over time.

Yes. Organizations that use cloud infrastructure remain responsible for implementing appropriate security, governance, and risk management measures under the shared responsibility model. This includes maintaining secure configurations, controlling changes, and demonstrating compliance across cloud environments.

NIS2 requires organizations to manage cybersecurity risks on an ongoing basis rather than relying only on periodic audits. Continuous compliance ensures infrastructure remains aligned with defined security standards over time, reducing the impact of configuration drift and improving the ability to demonstrate compliance when required.

Multi cloud environments increase the complexity of maintaining consistent security policies, governance, and compliance across different cloud providers. Without standardized infrastructure and continuous governance, organizations often face configuration drift, fragmented controls, and more complex audits.

Security by Design means that security requirements are built directly into the infrastructure definition rather than being added after deployment. Security controls such as access policies, network isolation, encryption, and auditing are applied automatically whenever an environment is provisioned, ensuring consistent protection across all deployments.

Built in compliance means that security, regulatory and organizational rules are written into the reusable infrastructure standards rather than checked after deployment. Every environment created from those standards inherits the controls without anyone applying them by hand. One boundary matters here: this covers the infrastructure layer. It makes an environment audit ready, and it does not certify the application running on top, which stays the responsibility of whoever builds it. Formal compliance is always signed off by an external auditor.

Cloud environments constantly evolve through updates, configuration changes, and operational activities. Continuous governance helps ensure that deployed environments remain aligned with security and compliance standards by detecting configuration drift and enabling timely remediation throughout the infrastructure lifecycle.

Traditional security reviews validate infrastructure after it has been deployed, often requiring manual assessments and remediation. Security by Design embeds security requirements directly into the infrastructure definition, ensuring that compliant environments are created from the start and remain aligned with organizational standards throughout their lifecycle.

A dedicated tenant environment is an isolated infrastructure instance created for a single customer. It typically includes dedicated compute resources, networking, databases, security policies, and monitoring. Dedicated environments are commonly used in regulated industries where isolation, compliance, data residency, and customer specific requirements are essential.

Enterprise customers often require stronger isolation, regulatory compliance, customer specific security policies, data residency, and contractual service levels. Dedicated environments help organizations meet these requirements while reducing the risks associated with shared infrastructure.

By provisioning every tenant environment from the same versioned definition instead of maintaining each one individually. The environments stay identical where they should be, security controls are applied by construction rather than customer by customer, and an update or a security patch is applied to the definition and then propagated. In the published use cases a new tenant is provisioned from a webhook in about ten minutes with no human involved, and a CVE patch is rolled out across roughly sixty dependent Live SystemsThe running systems created from Fractal Cloud patterns. A Live System is the real cloud deployment that application teams use, operate and evolve. in controlled waves.

Multi tenant SaaS is a software architecture where a single application serves multiple customers, known as tenants. Depending on security, compliance, and business requirements, tenants may share infrastructure or run in dedicated environments while using the same application platform.

The Component → Service → Offer model separates infrastructure into three abstraction levels. A Component defines the required capability, a Service specifies the delivery model, and an Offer maps that capability to a provider-specific implementation. An example: the Component is Container Platform, the Service is Kubernetes, and the Offer is EKS on AWS, AKS on Azure or managed Kubernetes on Hetzner. The definition names the Component. The Offer is resolved at deployment time from the target provider, which is why one definition works on more than one cloud.

A Cloud Agent is a lightweight process that runs inside the customer's own cloud environment. On each cycle it reads the desired state from the control planeThe Fractal Cloud coordination layer. It stores infrastructure intent, reusable patterns and platform metadata while Cloud Agents perform the actual work inside each environment., reads the actual state from the cloud provider's API, compares the two and reconciles the difference. It works with the customer's own IAM roles and service accounts, so the control plane never stores cloud credentials. It talks to the control plane through outbound connections only: no inbound access, no open ports or VPN.

A Blueprint defines the versioned structure of an infrastructure system, including its components and integrations. A Fractal extends the Blueprint by adding a versioned Interface that defines the operations allowed across the infrastructure lifecycle. When instantiated, a Fractal becomes a governed Live System. The Blueprint says what the system is made of, for example a Kubernetes cluster, a managed database, a load balancer and the network rules between them. The Interface says what a team may do with it afterwards, for example scale the cluster and add a namespace, but not disable encryption or open the network. The Fractal is the two together, which is why it can be operated over time and not only described.

Developer self service allows application teams to provision and manage approved infrastructure without opening tickets or waiting for manual intervention. Platform Teams define reusable standards and governance, while Development Teams consume those capabilities through predefined workflows that ensure security, compliance, and operational consistency.

Infrastructure as Code automates infrastructure provisioning, but it does not guarantee that governance is applied consistently throughout the infrastructure lifecycle. Organizations still need mechanisms to enforce architectural standards, manage lifecycle operations, prevent configuration drift, and maintain compliance across all deployed environments.

Usually because the platform team ends up owning execution rather than standards. Every new requirement becomes a ticket for them, every unusual case becomes an exception only they can handle, and the abstraction layer built to hide complexity has to be extended by hand each time reality does not fit inside it. The symptom is easy to recognize: developers start going around the platform because the direct route is faster, and the platform team spends its time on requests instead of on the platform.

Intent-based operations let a team state the outcome it needs instead of the steps to get there: an environment for a new customer, a database for this service, a second region for recovery. The platform translates that request into approved standardized operationsCommon operational practices embedded into infrastructure patterns. Examples include tagging, monitoring, backup policies, secure defaults and controlled emergency override. that already carry the governance, security and operational rules. The team does not have to describe how. It also cannot skip the rules, because the translation is the only route to execution.

Constrained Freedom is an operating model where developers have the autonomy to provision and manage infrastructure within predefined architectural boundaries. Developers use approved platform capabilities that embed security, governance, and operational standards, allowing teams to work independently without routine manual approvals.

Developer portals simplify access to platform capabilities, but they do not provide governance by themselves. Modern Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. focuses on the underlying operating model, where standardized BlueprintsReusable infrastructure patterns created by platform teams. Blueprints give delivery teams a trusted starting point for secure, compliant and production-ready systems., automation, and policy enforcement ensure consistent infrastructure regardless of the user interface. The portal becomes a user experience layer, while governance resides in the platform itself.

TicketOps is the operating model where a developer who needs a database, a namespace or a firewall rule opens a request and waits for someone else to carry it out. The problem is not the approval. It is that the approval is welded to the execution, so a change worth ten minutes of work can take four days of queue. Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. separates the two: the rules are decided once and encoded in the platform, and execution becomes self-service inside those rules.

Cloud sovereignty is the ability of an organization to keep control over its data, its workloads and its infrastructure decisions. It has three dimensions that often get treated as one. Technical: you can move, rebuild and operate your systems without depending on a single vendor's tooling. Operational: you decide who can access what, and you can prove it. Legal: you know which jurisdiction governs the provider and the data, which depends on where the provider is established and not only on where the data centre is. Provider choice determines the legal dimension. Architecture determines the other two.

An exit strategy ensures that an organization can move workloads, applications, and data away from a cloud provider within acceptable timeframes and costs, without disrupting business operations, if business, regulatory, or operational requirements change. Without a realistic exit strategy, organizations remain exposed to vendor dependency regardless of their compliance posture.

No, but it does mean being precise about which part of sovereignty you are solving. Architectural and operational control can be achieved on a hyperscaler: standardized patterns, governed access, a documented way out. Legal exposure is a different question. If a provider is subject to a non EU legal framework, no architectural choice removes that, and for a small set of workloads it is the deciding factor. Most organizations end up with a mix: hyperscalers where the services matter most, EU providers where jurisdiction matters most, and the same architecture on both.

Reducing vendor lock in starts with architecture rather than provider selection. Organizations should standardize application patterns, separate governance from infrastructure, and avoid unnecessary architectural dependencies on provider specific implementations. This makes future migrations easier while preserving access to cloud native capabilities.

An Independent Control PlaneThe Fractal Cloud coordination layer. It stores infrastructure intent, reusable patterns and platform metadata while Cloud Agents perform the actual work inside each environment. is a governance layer that operates independently of the underlying infrastructure. It centrally manages policies, identities, security, and lifecycle operations across cloud providers, on premises environments, and edge infrastructure. By separating governance from the execution infrastructure, organizations can maintain consistent governance while reducing dependency on vendor specific services, regardless of where workloads run.

Provisioning creates an infrastructure environment only once. Day 2 Operations cover everything that happens afterwards: updates and patching, configuration changes, scaling, backup and recovery, compliance evidence, and eventually decommissioning. Day 1 lasts a few minutes. Day 2 lasts as long as the system is in production, which is where most of the cost and most of the risk sit.

Configuration drift is the gap that opens between how infrastructure is supposed to be configured and how it actually is. It usually starts legitimately: someone widens a security group at two in the morning to restore a service and never narrows it again, a setting gets changed in the console instead of in code, one environment receives an update and another does not. Each change is small and reasonable. The effect is that the description of the system stops being true, so troubleshooting starts from wrong assumptions and audits turn up things nobody remembers doing.

Because provisioning is a one-time event and maintenance is a permanent obligation. An environment that was correct on the day it was created starts to move: someone applies an emergency fix in the console, a policy changes, a CVE requires the same patch on every system sharing a component. If nothing keeps the environment aligned with its definition, the gap grows quietly and surfaces during an incident or an audit. The useful measure of a platform is not how fast it creates an environment. It is what that environment looks like six months later.

Drift is prevented by continuously comparing the deployed environment with its declared definition and correcting the difference, rather than checking during planned runs. Three things make that possible: one versioned definition of what the environment should be, automated comparison against the real state, and a controlled path for legitimate changes so that people are not pushed to go around the system. Detection on its own is not enough. A drift report nobody acts on is just a longer list every week.

Cloud agnostic means designing applications around standardized architectural patterns rather than provider specific services. Instead of making every implementation identical across clouds, the goal is to keep the architecture consistent while allowing each cloud provider to use the services that best match the required capabilities.

No. Multi cloud describes the use of multiple cloud providers within the same organization. Cloud agnostic is an architectural approach that standardizes application design across providers. A company can use multiple clouds without having a cloud agnostic architecture, and it can adopt a cloud agnostic architecture even if it currently operates on a single cloud.

No. A modern cloud agnostic strategy does not require avoiding cloud native services. Instead, it defines a common architectural pattern while allowing each cloud provider to implement that pattern using its own optimized services. This approach combines architectural consistency with cloud native performance.

Standardizing architecture means every environment follows the same governance, security and operational rules, whichever provider it runs on. Designing for literal portability means restricting yourself to what all clouds have in common, which usually rules out the managed services that made the cloud worth using. One choice shows the difference. Standardization says every application gets a managed relational database with encryption, backup and private networking, and accepts that this is RDS on AWS and Azure Database for PostgreSQL on Azure. Portability says run your own PostgreSQL on virtual machines everywhere so that it is identical, and then keep running it yourself forever.

Hetzner is a European provider, so both the infrastructure and the company that operates it sit under EU jurisdiction. That answers two of the three questions sovereignty raises: where the data is stored, and whose law governs the provider. The third question is whether you can leave. Fractal Cloud answers that one: the same versioned definition used to provision a Hetzner environment provisions the equivalent environment on another provider, so choosing Hetzner does not create a new dependency.

Yes. Fractal Cloud supports production ready Kubernetes environments on Hetzner Cloud with security, resilience, and operational best practices built in. Platform Teams can standardize Kubernetes environments, while Development Teams deploy and manage applications through reusable BlueprintsReusable infrastructure patterns created by platform teams. Blueprints give delivery teams a trusted starting point for secure, compliant and production-ready systems. and automated workflows.

Fractal Cloud automates the provisioning and lifecycle management of Kubernetes environments on Hetzner Cloud. Platform Teams define reusable blueprintsReusable infrastructure patterns created by platform teams. Blueprints give delivery teams a trusted starting point for secure, compliant and production-ready systems. with built in security, governance, and operational controls, while Development Teams deploy and manage applications through standardized workflows without dealing with provider specific infrastructure details.

Yes, with one distinction worth making. Fractal Cloud recreates the target environment on the new provider from the same versioned definition, so the architecture, the policies and the operational setup come across unchanged. Application data and persistent state still have to be moved with the appropriate replication or backup and restore process. What normally makes a migration expensive is rebuilding and re-certifying the environment, and that part is already described in the Fractal.

Disaster Recovery is the set of strategies, processes, and technologies used to restore applications and infrastructure after a failure or service disruption. In cloud environments, Disaster Recovery aims to minimize downtime and data loss by preparing recovery environments that can be activated quickly when needed.

Because a recovery plan is only as good as the last time it was tested, and manually maintained recovery environments are rarely identical to production. When both come from the same versioned definition, the recovery environment is not a reconstruction, it is another instance. That also makes testing cheap enough to run regularly: in the published use cases a full environment is brought up in a second region in about five minutes, which turns a disaster recovery test from a scheduled project into a routine check.

Recovery Time Objective (RTO) is the maximum acceptable time to restore a service after an outage. It is a business decision before it is a technical one: an internal reporting tool might tolerate a day, a payment service might tolerate minutes. The number chosen determines the architecture and the cost, because the gap between one hour and five minutes is the gap between rebuilding an environment on demand and keeping a second one warm. RTO is always set alongside RPO, which covers how much data can be lost.

Resilience by Design is an architectural approach where resilience requirements are built into infrastructure from the beginning instead of being added through manual Disaster Recovery procedures. Standardized architectures, automation, and governed infrastructure enable organizations to recover more quickly, maintain consistent environments, and simplify Disaster Recovery operations.

Business Continuity is the overall strategy that ensures an organization can continue delivering critical business services during and after a disruptive event. Disaster Recovery is a subset of Business Continuity focused specifically on restoring IT systems, applications, and infrastructure after a failure. While Business Continuity addresses people, processes, and operations, Disaster Recovery concentrates on recovering technology within defined recovery objectives such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

Infrastructure as Code solved a real problem: infrastructure became described, versioned and repeatable. Its limits show up with scale rather than with correctness. Configuration languages offer little support for the practices that keep a large codebase manageable: abstraction, shared libraries, type checking, design patterns, unit tests. The usual result is copy and paste between modules, glue scripts around the tool, and a growing amount of code that only one or two people fully understand. The tooling is not wrong. It was built to describe infrastructure, and it is being asked to model it.

An SDK allows infrastructure to be defined using a general purpose programming language instead of configuration files. Developers can build reusable libraries, apply software design patterns, validate infrastructure through type safety, and write unit tests, making Infrastructure as Code easier to maintain, extend, and scale.

YAML is effective for describing configuration, but managing complex infrastructure often requires abstraction, composition, validation, and reusable logic. As infrastructure grows, large configuration files can become difficult to maintain and evolve. A programming language allows infrastructure to be modeled as software, making complex systems easier to organize, test, extend, and maintain.

Platform as a Product is a Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. approach where the internal platform is treated as a product designed for developers and operations teams. The Platform Team continuously improves the platform based on user needs, making secure, compliant, and reusable infrastructure the easiest option to adopt.

A Golden Path is a pre-approved route to a common outcome: deploy a web application, add a database, create a test environment. The Platform Team builds and maintains it, the security and compliance decisions are already inside it, and it is the fastest option available. That last part is what makes it work. Governance holds because the compliant route is also the route of least resistance, not because the alternatives are forbidden.

Cognitive load here means the number of things a developer has to keep in mind that have nothing to do with the feature they are building: which network setup this cloud expects, which IAM permission the service needs, which security policy applies in production. Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. moves those decisions into reusable platform capabilities where they have already been made once. The developer asks for a database and gets one that is encrypted, backed up and monitored, without learning how each provider configures it.

Operational complexity in Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. is the accumulation of manual processes, disconnected tools, and inconsistent infrastructure practices that slow software delivery and increase operational risk. It typically results from managing provisioning, security, monitoring, compliance, and lifecycle operations through separate systems, creating duplicated work, fragmented governance, and inconsistent infrastructure across teams and environments.

Fractal Cloud reduces operational complexity by replacing fragmented infrastructure workflows with reusable Fractals that combine automation, governance, security, and operational standards. Platform Teams define these Fractals once, while Development Teams instantiate them through controlled self service interfaces. The Fractal Automation Engine manages provisioning, configuration, updates, and continuous reconciliation to keep environments aligned and prevent configuration drift throughout the infrastructure lifecycle.

Fractal Architecture is a Platform EngineeringThe practice of giving teams paved, reusable paths for software delivery. Fractal Cloud supports platform engineering by turning cloud standards into self-service infrastructure products. model that organizes infrastructure into modular, composable, and versioned components. It enables Platform Teams to define secure, governed infrastructure capabilities while Development Teams consume them through controlled interfaces without managing the underlying implementation. Each instantiated Fractal becomes a continuously governed Live System. The comparison that makes this concrete is software libraries. Nobody rewrites an HTTP client for every application: someone writes it once, it gets a version number, and everyone else imports it. Fractal Architecture applies that to infrastructure. A production-ready Kubernetes environment is defined once, versioned, and instantiated by the teams that need it.