korta01 / WRITE
#
Describe the state.
Write a role in Markdown in the web editor, or in your own editor and upload it with the CLI. The editor shows each step as you type and reports unreadable lines with their line number.
#Operations for
Operations for
the whole team.
Korta Enterprise is a self-hosted manager and web console for the Korta CLI. Plan, approve, deploy and audit Markdown roles across your servers, cloud instances and databases, on infrastructure you own.
The same korta CLI and role files work with the manager. Nothing runs without a plan, and every approval is recorded.
## WORKFLOW
Write, review,
then apply.
Every change follows the same path, whether a person or Claude wrote the role.
02 / PLAN
?
See every change.
A plan shows what would change on each host and changes nothing. A plan expires after 24 hours or once applied, and only the newest plan for the current role can be approved.
03 / APPROVE
↗
Apply exactly that plan.
Approval applies the plan you reviewed, a batch of hosts at a time, and stops after a failed batch. Changing a role or its labels after planning invalidates the plan.
## WHAT IT MANAGES
Databases, apps
and cloud instances.
Korta installs software natively under systemd from official repositories, with TLS, encrypted secrets and backups by default. Hosts need only SSH with root or passwordless sudo.
01PostgreSQL 14 to 17
Roles, databases, TLS, network access rules, and pgBackRest backups to local disk or S3 with point-in-time restore.
02MySQL 8.4 LTS and 9.7 LTS
Users, databases, TLS, IPv4 access rules, and encrypted daily dumps with binary-log point-in-time restore.
03Node.js and Next.js from Git
Built once, shipped to every instance, run under systemd. Health-checked rollouts roll back automatically, and apps can link to a database deployment.
04AWS and Google Cloud instances
A role launches instances on AWS or Google Cloud, configures them after launch, and destroys them when you ask. On AWS, networks, static IPs, load balancers and DNS names are part of the same role.
05Roles in Markdown
Packages, users and groups, files, services, sysctl settings, firewall ports, variables and templates. Custom scripts need an extra confirmation.
## ACCESS AND APPROVALS
Give each person
only what they need.
Grants pair an access level with everywhere, or with the instances whose labels match a scope. Each level includes the ones above it.
viewer
Read instances, deployments, roles, plans and operations.
operator
Check instances, open consoles, apply deployments, and edit and plan roles.
approver
Approve role plans, restore databases and read connection credentials.
admin and owner
Manage deployments, instances, SSH keys, secrets and users. Owners manage grants.
FOUR-EYES APPROVAL
By default, nobody approves a role they last changed or planned. Turn this off with KORTA_FOUR_EYES=false for single-person teams. Users add an authenticator app, and create personal API tokens for the CLI and CI, valid for 90 days by default.
## AUDIT AND CONSOLE
Know who did
what, and when.
Every approval, console session and change is in the audit log. Console sessions show their opening and closing on the instance page.
Open an interactive SSH terminal from the web console. It logs in as the instance's configured SSH user, uses the stored key and pinned host key, and follows your access grants. Idle sessions close after 30 minutes, with an eight-hour maximum.
Read about console access ↗> AUDIT TRAIL
01 Role approved ✓
02 Console opened ✓
03 Deployment applied ✓
EVERY CHANGE / ON RECORD## SECURITY
Secure by
default.
Secrets and keys never leave the manager in plain text, and plans never store the values they would use.
Encrypted at rest.
SSH keys and named secrets are sealed with AES-GCM under a vault key you back up. Secret values are write-only and never shown again.
Pinned SSH identity.
Korta pins each host's key on first connection and refuses a changed key until you trust it again.
Plans hold no secrets.
Plans store keyed hashes of compiled roles, and secret values stay out of plans, logs and operation results.
A private certificate authority.
The manager runs its own CA for PostgreSQL and MySQL TLS, so database connections are encrypted without public certificates.
## AI ASSISTANT
Draft roles with Claude.
Approve them yourself.
Describe what hosts should look like. Claude proposes a role, and Korta checks it with the same validation as a role written by hand. The assistant never applies anything.
01
02
03
02
03
"Patch prod weekly, one host at a time, reboot only if needed, and keep nginx running." → role saved, plan created, awaiting approval
$ Claude sees instance names and labels, ↵
It never sees addresses, keys or passwords. Revise an existing role the same way.
## RUN THE MANAGER
Start with
your own infrastructure.
Run the manager on a server you control. Use PostgreSQL for production, with the vault key and admin token kept outside the database and the container.
01
02
03
04
02
03
04
export KORTA_DATABASE_URL='postgres://korta:…@db.internal/korta' export KORTA_VAULT_KEY="$(openssl rand -base64 32)" export KORTA_ADMIN_TOKEN="$(openssl rand -base64 32)" korta-server