Environment commands

The env commands manage environments — the deployable units that hold your infrastructure resources on your cloud account. (In the API an environment is called a stage; the CLI calls it an environment.)

All env commands need a project id. Pass --project <id> or set MICROTICA_PROJECT_ID.

Inspect environments

env list

List the environments in a project with their id, name, and status.

microtica env list

id                    name         status
--------------------  -----------  ---------------
Production-aB12cD3eFg  Production   UPDATE_COMPLETE
Development-fQI6w86lyd Development  NOT_DEPLOYED

Status follows the CloudFormation-style vocabulary: NOT_DEPLOYED, and CREATE/UPDATE/DELETE paired with _IN_PROGRESS, _COMPLETE, or _FAILED. Environment ids take the form <DisplayName>-<suffix>.

env get

Show one environment's top-level metadata — cloud provider, region, IaC tool, status, and last-deploy info.

microtica env get <envId>

env get-details

Show the full environment, including each resource and its complete configurations array.

microtica env get-details <envId>

# Just the resource names and their status
microtica env get-details <envId> --query "resources[].{name: name, status: status}"

env get-resource

Show one resource's full configuration within an environment.

microtica env get-resource <envId> <resourceName>

Resource names are case-sensitive.

env last-deploy

Answer "when was this resource last deployed to this environment, from what commit, by whom?" in one call.

microtica env last-deploy <resourceName> --env <envId>

Resources in one environment deploy together as a single run, but each can sit at a different commit. This command returns the environment run's timestamps alongside the specific resource's commit and per-resource status, so you don't conflate the two.

Deploy and wait

env deploy

Trigger a deployment of an environment. The command returns immediately with the queued deployment id — pair it with env wait to block until it settles.

# Deploy the whole environment
microtica env deploy <envId>

# Deploy only specific resources (repeatable)
microtica env deploy <envId> --partial-resource WebApp --partial-resource Api

A partial deploy is required on a first deploy when a downstream resource reads an upstream resource's outputs at plan time — for example, EKS depending on a VPC's subnet ids. Deploy the upstream resource first, then the rest.

env wait

Block until every resource in an environment reaches a terminal status (*_COMPLETE or *_FAILED).

microtica env wait <envId> --timeout 1800 --poll-interval 10

Clone and replicate

env clone

Clone a source environment into a new one. This copies resources and their configurations — applications deployed inside the cluster are not copied.

microtica env clone <sourceEnvId> --to Staging

Cloning is idempotent: if an environment with the same name already exists, the command returns it instead of creating a duplicate. After cloning resources, deploy them with env deploy, then deploy your apps separately.

env replicate

Run the whole clone-to-running flow in one command: clone the source, apply overrides from a YAML/JSON file, deploy the resources, then deploy the apps.

microtica env replicate <sourceEnvId> --to Staging --overrides ./overrides.yaml

Use --phase resources to clone and deploy infrastructure only, or --phase apps to deploy apps into an already-deployed target — for example after a wrapper script has rendered per-target secrets.

Manage resources

env add-resource

Add a new resource — an instance of a component — to an environment. Its configuration must satisfy the component's config schema for the chosen version.

# See the config schema for the component version first
microtica env add-resource <envId> --component <componentId> --name my-db --show-schema

# Then create the resource
microtica env add-resource <envId> \
  --component <componentId> --name my-db \
  --set engine=postgres --secret db_password=s3cret

The CLI validates your config against the schema before creating the resource: missing required keys fail, and keys the schema forbids are rejected.

env update-resource

Update a resource's configuration. By default the CLI merges your values onto the existing configuration, so you only pass what changes.

# Merge: override just these keys, keep the rest
microtica env update-resource <envId> <resourceName> --config-file ./changes.yaml

# Replace the whole configuration set
microtica env update-resource <envId> <resourceName> --config-file ./full.yaml --no-merge

env remove-resource

Remove a resource from an environment's spec. This is a spec change only — it doesn't tear down already-provisioned infrastructure. Run env deploy afterward to reconcile.

microtica env remove-resource <envId> <resourceName>

Tear down

Both teardown commands are destructive and ask you to retype the environment id to confirm. Pass --yes to skip the prompt in scripts; without a terminal and without --yes, they refuse to run.

env undeploy

Destroy all the cloud resources an environment owns (terraform destroy / CloudFormation delete-stack). The Microtica environment record is preserved.

microtica env undeploy <envId>

env delete

Remove the environment's Microtica record. Run undeploy first if cloud resources are still up — otherwise they become orphans.

microtica env delete <envId>

Next steps

• Deploy applications into an environment
• Stream a deployment's logs
• How environments work