Application commands

The app commands manage applications deployed to Kubernetes — the microservices running inside your environments' clusters. They cover scaling, deployment, status, and logs.

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

Resolving cluster and namespace

Several commands need to know which cluster and namespace an app runs in. You can give them explicitly with --cluster and --namespace, or let the CLI resolve them:

• Pass --env <id> and the CLI finds the app in that environment.
• With no --env, it searches the whole project.
• If the app runs in more than one place, the CLI lists the candidates and asks you to disambiguate.

The deploy primitives (declare, deploy, update-config, status) take an explicit --cluster and default --namespace to microtica.

Inspect apps

app list

List the apps deployed in an environment, or across the whole project.

# Grouped by namespace, with a normalized lastDeployedAt timestamp
microtica app list --env <envId>

# Everything in the project
microtica app list

app get

Show a single app's microservice document. Add --version <v> to read a specific version.

microtica app get <name>

app status

Show pod-level deployment status for an app in a cluster.

microtica app status <appName> --cluster <clusterId> --namespace <ns>

app last-deploy

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

microtica app last-deploy <name> --env <envId>

--include-raw attaches the underlying pipeline record. This is the app counterpart to env last-deploy — use it for Kubernetes apps, which each have their own deploy timeline.

Scale apps

For scaling, reach for app resources and app replicas. They read the live configuration, merge your changes, round-trip sensitive values safely, and redeploy. Both are dual-mode: with no value flags they print the current settings; with value flags they apply the change.

app resources

Show or set pod CPU and memory requests and limits, then redeploy.

# Show current resources (auto-resolves cluster/namespace from --env)
microtica app resources <name> --env <envId>

# Set CPU, memory, and a memory limit, then roll the pods
microtica app resources <name> --env <envId> --cpu 1000m --memory 1Gi --memory-limit 2Gi

Use the binary memory units (Mi, Gi); SI units like M and G are rejected to avoid confusion. A request that would exceed its limit is rejected before any deploy runs.

app replicas

Show or set the HPA replica bounds, then redeploy. Replica-only changes reconcile the autoscaler without rolling pods.

# Show current bounds
microtica app replicas <name> --env <envId>

# Set min and max
microtica app replicas <name> --env <envId> --min 2 --max 5

A one-sided change that would cross the other bound — say --min 10 when the stored max is 5 — is rejected before redeploying.

See Scale applications for the underlying concepts.

Deploy apps

These are lower-level primitives. The platform's pipelines deploy apps for you on a Git push, so reach for these only when you're scripting a deploy directly.

app deploy

Apply an app to its target cluster — create Kubernetes secrets and run the rollout. Deploying the same image that's already live returns early without re-applying.

microtica app deploy <appName> --cluster <clusterId> --image <image> --config-file ./config.json

The config file is an array of entries. Mark secrets with "sensitive": true:

[
  { "key": "DOMAIN_NAME", "value": "api.example.com" },
  { "key": "DB_PASSWORD", "value": "<plaintext-or-secretName:KEY>", "sensitive": true }
]

The safe way to edit config is to round-trip it through app status, which returns this exact shape:

microtica app status <name> --cluster <id> --query 'configurations' > config.json
# edit config.json — keep the array shape and the `sensitive` flag on each secret
microtica app deploy <name> --cluster <id> --image <img> --config-file config.json

app declare

Register an app and its non-sensitive configuration without applying anything to the cluster. Secrets are dropped on declare — re-supply them on the next app deploy. Same flags as app deploy.

microtica app declare <appName> --cluster <clusterId> --image <image> --config-file ./config.json

app update-config

Overwrite an app's stored configuration without redeploying. Like app deploy, it replaces the full set, so --config-file is required.

microtica app update-config <appName> --cluster <clusterId> --image <image> --config-file ./config.json

app logs

Fetch an app's pod logs. This is an alias for microtica logs app — both share the same flags and behavior.

microtica app logs <name> --env <envId>

Next steps

• Stream app logs
• Scale applications
• How applications work