Importing existing infrastructure

Facets can adopt infrastructure you already run without rebuilding it. Praxis finds it, maps each resource to a module, and imports it into Facets' own Terraform state.

Facets changes only the resources it manages, and only through releases. Resources you haven't brought into Facets stay as they are.

Releases: a person or Praxis starts most of them. Scheduled releases and maintenance windows start on their own once you set them up.
Finding what you run: Praxis uses read-only cloud commands (How Praxis works and stays safe).
The import: changes nothing, or only what you approve, depending on which import you run.

What importing does

Importing adopts a running resource as it is, whoever made it: a person in the console, Terraform or another tool.

Find
Read-only discoveryPraxis lists what runs in your cloud account
maps each resource to a
Map
Module and blueprint resourceA catalog module, or one Praxis writes, set to match the live resource
checked with a
Check
PlanNothing may be destroyed or replaced. In a zero-change import, nothing may change at all
if it passes, an
Adopt
ImportRecords each resource in Facets' Terraform state, without changing it
from then on managed through
Manage
ReleasesLater changes go through plan, approval and apply, like anything built in Facets

Imports work on AWS, GCP and Azure, and on other Terraform providers such as MongoDB Atlas.

To move a resource to another cloud or setup instead, Facets creates a new one, you copy the data, then switch over (Adopt and migrate infrastructure).

Zero-change or standard import

A zero-change import changes nothing. A standard import can also make small in-place changes you approve.

	Zero-change import	Standard import
Use it for	Adopting running resources as they are	Fixing small differences while adopting
What it may change	Nothing: no creates, changes, destroys or replacements	In-place changes you approve after Praxis explains the risk. No destroys or replacements
When the plan shows a difference	The module or blueprint is changed to match the live resource, then planned again	You choose: ignore the field, allow the change, or make it a setting

With the Praxis CLI, a zero-change import uses an import release: the control plane refuses to apply it if anything would be created, changed or destroyed, even a tag.

raptor create import-release -p PROJECT -e ENVIRONMENT -t TYPE/NAME --imports-file ./imports.tf -w

Import releases need the Import permission, which only admins have by default (Access control).

Resources that don't fit a module

Praxis writes a module for them, or you keep them out of Facets. Discovery flags each one, so you decide.

Praxis writes a module

Built from the live resource's settings, published to your catalog, then used to import it.

Reference it from outside

Add it as a provided resource: Facets leaves it alone, and services can use its outputs.

Leave it out

It keeps running as it is, outside Facets.

Praxis asks before including resources made by hand, and leaves out those your cloud provider creates for its own services.

To keep a resource outside Facets, add it to the blueprint as a provided resource. Facets doesn't create, change or delete it.

You type in its outputs, such as a database's host and port. They're stored in the blueprint, in Git.
Your services read its address and credentials like any other resource's, for example ${postgres.main-db.out.interfaces.writer.host}.

Your existing Terraform state

Facets keeps its own Terraform state for each environment and imports running resources into it, one by one. It can't use an existing state file or backend.

Stop the old tool

Facets doesn't change your old state, which still lists the resources you imported. Stop the old tool from managing them, so two tools don't change the same resource.

Your Terraform code still helps: Praxis compares it with what's live when it builds the modules.