Enterprise modules

Korta Enterprise adds modules for the platform: the manager, deployments, cloud instances, secrets, access control, the audit log and the AI assistant. Each one is used from the web console or the korta CLI, and every change goes through a plan that someone approves.

Module	What it does	Guide
Instances	Registers the hosts that Korta manages, with their SSH key	Instances
PostgreSQL	Databases and roles, TLS, network rules, backups and restore	Deployments
MySQL	Databases and users, TLS, network rules, dumps and restore	Deployments
Node.js and Next.js	Applications from Git, with rollouts and rollback	Deployments
AWS instances	Creates and configures EC2 instances from a role	AWS
Google Cloud instances	Creates and configures Compute Engine instances from a role	Google Cloud
Roles	Markdown roles, plans, approvals and applies	Roles
Secrets	Encrypted values for roles	Secrets
Access	Users, access levels and API tokens	Access
Audit and console	The audit log, operations and an SSH terminal	Audit and console
AI assistant	Drafts and revises roles with Claude	AI assistant

Instances

An instance is a host that the manager configures over SSH. Store its private key once, then register the host.

korta keys create deploy --private-key ~/.ssh/korta_ed25519
korta instances create db1 --host 10.0.0.5 --user ubuntu --key KEY_ID --label env=prod
korta instances check INSTANCE_ID

instances check reconnects and records the operating system, kernel, CPU, memory, root disk usage and every global IP address. The host key is pinned on first connection. After a known reinstall, run instances trust-host-key.

Deployments

A deployment keeps a service running on one or more instances. Choose a type, describe what it needs in a JSON spec, and apply it. Korta installs the software natively under systemd from official repositories, with TLS and backups.

korta deployments create orders-db --type postgres --instance INSTANCE_ID --file orders-db.json
korta deployments status DEPLOYMENT_ID
korta deployments connection DEPLOYMENT_ID --role orders --database orders

Type	Versions	Spec highlights
postgres	14 to 17	roles, databases, access (network rules), backup (local disk or S3 with point-in-time restore)
mysql	8.4 LTS, 9.7 LTS	users, databases, access, backup (encrypted daily dumps with binary-log restore)
node	Node.js from Git	repository, ref, port, healthPath, env, secretEnv, database link
nextjs	Next.js from Git	As node; enable output: "standalone" in next.config.js for smaller releases

A PostgreSQL spec:

{
  "roles": [{ "name": "orders" }],
  "databases": [{ "name": "orders", "owner": "orders" }],
  "access": [{ "database": "orders", "role": "orders", "cidr": "10.0.0.0/16" }],
  "backup": {}
}

Applications use the same pattern. Korta builds a release once on the first instance, copies it to the others, and switches one batch at a time. A release that fails its health check rolls back on that instance and stops the rollout.

korta deployments restart DEPLOYMENT_ID
korta deployments rollback DEPLOYMENT_ID
korta deployments backups DEPLOYMENT_ID
korta deployments backup DEPLOYMENT_ID
korta deployments restore DEPLOYMENT_ID         # see `korta deployments restore --help`

An application can link to a database deployment with database, and Korta injects the connection settings. Give a database a DNS name in its tlsNames if the application's PostgreSQL driver verifies certificates.

AWS

Add AWS accounts under Settings > AWS > Accounts. Each account signs in by assuming an IAM role (recommended), with an access key, or with the manager's own environment. Roles never contain credentials. The IAM policy and every option are in the AWS provisioning guide.

A role creates the instances it describes:

# AWS instance
- name: web
- count: 2

# Firewall
- open 443/tcp from anywhere

# Packages
- nginx

Korta chooses the official image, the network, an SSH key and a security group, launches the instances and configures them. Destroy terminates the instances the role created. Networks, static IPs, load balancers and DNS names are part of the same role. See AWS networking.

Google Cloud

Under Settings > Google Cloud, choose how the manager authenticates: Application Default Credentials (the default), or a service-account key that the vault encrypts. The same role format creates Compute Engine instances:

# GCP instance
- name: web
- project: my-gcp-project
- zone: europe-west1-b
- subnet: default

See Google Cloud credentials for the permissions and the Shared VPC requirements.

Roles

A role is a Markdown file. Create it, plan it, then approve the plan.

korta roles create --file site.md --name site --label env=prod
korta roles plan ROLE_ID
korta roles apply ROLE_ID --approve
korta roles run ROLE_ID          # plans, then applies after you confirm

Approval applies exactly the plan you reviewed. A change to the role, its labels, or a secret after planning invalidates that plan. Plans expire after 24 hours or once they are applied. Roles with custom scripts need --confirm-commands on approval. The role syntax is in the Markdown roles guide.

Secrets

Store secret values once, and refer to them in roles as {{ secret.NAME }}.

korta secrets set DB_PASSWORD --value-file ./db-password.txt
korta secrets list

Values are encrypted in the vault, never shown again, and kept out of plans, logs and operation results. Scheduled scripts can't use secret references.

Access

Grant each user an access level, everywhere or only on instances whose labels match a scope. Each level includes the ones above it.

Level	Allows
viewer	Read instances, deployments, roles, plans and operations
operator	Check instances, open consoles, apply deployments, edit and plan roles
approver	Approve role plans, restore databases, read connection credentials
admin	Create and delete deployments; with a global grant, also instances, SSH keys, secrets and the audit log
owner	Manage users and grants

Four-eyes approval is on by default: nobody approves a role they last changed or planned. Set KORTA_FOUR_EYES=false for single-person teams. Each user can add an authenticator app, and create personal API tokens for the CLI and CI, valid for 90 days by default.

Audit and console

Every approval, console session and change is in the audit log.

korta audit
korta operations list
korta operations get OPERATION_ID

Open an interactive SSH session on an instance with korta instances console INSTANCE_ID, or from the web console. The session logs in as the instance's SSH user, uses the stored key and pinned host key, and follows your access grants. It closes after 30 minutes without input, and after eight hours at most.

AI assistant

Describe what hosts should look like, and Claude drafts a role. Korta checks it with the same validation as a role written by hand, and a person approves the plan. The assistant never applies changes, and it sees instance names, labels and operating systems, never addresses, keys or passwords.

korta assistant start --role ROLE_ID
korta assistant send CHAT_ID --text 'patch prod weekly, one host at a time'
korta assistant save CHAT_ID

The assistant needs KORTA_ANTHROPIC_API_KEY on the manager. Without it, the rest of the platform works unchanged.

API

Everything the console and CLI do is available over the HTTP API at /api. The CLI, web console and API share the same access rules and the same audit log. Mutations return 202 with an operation to follow. A second change while one is running returns 409.