Your own cloud accounts

emma creates resources in two ways. Most of what you deploy goes through the emma platform: VMs, Kubernetes, volumes, and networks on the providers emma connects to, all living in your emma project. The other way is directly in a cloud account you own, using a credential you store in emma. This page covers the second way.

In a nutshell:

• You add a credential for an AWS, GCP, Azure, or Hugging Face account under Settings → Cloud Providers
• On every provider, emma can scan the account and look for waste
• On AWS, emma can also create and update a curated set of resource types, and run managed Postgres on RDS
• Changes to your own account go through the same confirmation gate, with stricter rules for anything destructive

Connect an account

Credentials are encrypted at rest and never enter the model's context. The copilot refers to a stored credential by its id and never sees the secret itself.

To remove a credential, open its row menu and click Delete. From then on, scans that use it fail, and you can't undo this.

What each provider enables

Scans and waste analysis are read-only. Waste analysis ranks idle or orphaned resources and recommends what to remove, but it never deletes anything. See Import existing infrastructure for bringing scanned resources under management.

Provision into your AWS account

In a stored AWS account, emma can create and update these resource types:

emma turns these into steps of a regular deployment plan, and a plan can mix steps for your own account with steps on the emma platform. If you ask for a type that isn't on the list, the copilot tells you it isn't enabled yet instead of trying.

What the plan shows

Each step that touches your own account gets a card:

• Target account: the AWS account, the region, and the name of the stored credential it uses.
• The action and the type: create, update, or replace, plus the AWS resource type.
• The property changes: each property the step adds, sets, or drops, with the old value next to the new one on updates. Properties that force AWS to recreate the resource are marked (replaces on change).
• Policy findings: warnings for public network exposure and missing encryption at rest. If a check can't be evaluated for a type, the card says it wasn't checked.
• Caveats: for example, that AWS adds its own defaults that aren't shown.

Confirmations

Creates and updates in your own account go through the confirmation gate like any other change. One rule is stricter here: if an update changes a property that makes AWS destroy and recreate the resource, the card shows it as replace, and it's gated as a delete. It asks for confirmation in every permission mode, Autonomous included.

If a step fails

When a plan fails partway, emma never deletes what it already created in your own account as a rollback. Those resources are kept, and the failure message says so. Fix the cause, then ask the copilot to retry the failed step.

Managed Postgres on RDS

With a stored AWS credential, the copilot can create a managed PostgreSQL database on Amazon RDS in your account.

• It's a real, billable RDS instance. The default is db.t3.micro with 20 GB of storage. AWS accepts the request in about 30 seconds, and the database takes a few more minutes to become available.
• It's private by default. Only workloads inside your VPC can reach it. You can ask for a public endpoint so VMs on the emma platform can connect. In that case emma refuses to create it if the security group lets anyone on the internet reach the Postgres port.
• You never see the password in chat. emma generates the master password, and once the database is available it stores the connection string, encrypted, as an environment variable in your environment (DATABASE_URL unless you ask for another name).
• Teardown is permanent and always confirmed. Deleting the database is gated as a delete in every mode. By default AWS takes a final snapshot first, and that snapshot stays in your account, where you manage it in the RDS console. emma only tears down instances it created.

What's next

• Cloud providers — the providers emma deploys to through the platform
• Import existing infrastructure — scan a connected account and adopt what's there
• Safety & confirmations — how the gate and permission modes work
• Deploy an app by chatting — a plan end to end