Why Korta

Korta configures Linux servers from Markdown files you can read, review and keep in Git. It connects over SSH, changes nothing until you approve a plan, and runs on your own machines. This page explains what that means in practice, and where Korta is not the right fit.

Simple to start

Install one binary, write a short role, and run it. There is no agent to install on each host, no server to set up first, and no YAML to learn.

# Packages
- nginx, curl

# Services
- nginx started, enabled

korta plan role.md -i hosts.md      # changes nothing
korta apply role.md -i hosts.md     # plans, asks, applies

Readable by everyone who reviews it

A role says what a host should look like, in the order a person would describe it. Headings name the area, and each bullet is one item. Reviewers read the change in a pull request without learning a configuration language.

Nothing changes without a plan

plan connects to each host and shows every change, and changes nothing. apply plans again, shows the result, and asks before it touches a host. In CI, --yes is an explicit choice. Korta applies in batches, one host at a time by default, and stops after a failed batch.

It does not guess

Anything Korta does not understand is an error with its line number. A role that looks almost right is not applied as an approximation. Unknown module names, missing values and conflicting settings are reported before a host is touched.

No agent, no extra access

Hosts need SSH access with root or passwordless sudo, and nothing else. Korta uses your own SSH configuration, keys, agent and known_hosts. Keys can be named per group in the inventory, or stay in your agent.

Your servers, your control

The core CLI runs on your machine or in CI. Korta Enterprise is a manager you host yourself, on your own infrastructure, with PostgreSQL or files for its state. Your roles, inventories and host data stay where you put them.

What Korta Enterprise adds

Korta Enterprise is for teams that share operations:

• Approval before change. A plan needs approval from someone else (four-eyes by default), and approval applies exactly the plan that was reviewed.
• An audit log. Approvals, console sessions and changes are recorded.
• Access levels. Give each person viewer, operator, approver or admin access, everywhere or only to instances with matching labels.
• A vault. SSH keys and secrets are encrypted and never shown again.
• Deployments. PostgreSQL, MySQL, Node.js and Next.js run natively under systemd, with backups, rollouts and rollback.
• Cloud instances. Roles create AWS and Google Cloud instances and configure them, using accounts you connect to the manager.
• An AI assistant that drafts, never applies. Claude drafts or revises a role. A person reviews the plan and approves it.

How it compares

Configuration tools differ in what they need on each host, how they describe state, and where the control plane runs. These are the differences that matter most for Korta:

If you need	Korta
No software on managed hosts	Only SSH and sudo
Roles that anyone can read and review	Markdown, not YAML or a DSL
Visible changes before they happen	A plan for every run, with approval
Control plane on your infrastructure	Self-hosted manager, no SaaS requirement
Approvals, access levels and an audit log	Included in Korta Enterprise

Where Korta is not the right fit

• Windows hosts. Korta configures Linux hosts only.
• Continuous enforcement. Korta applies state when you run it. It has no agent that corrects drift in the background. Scheduled jobs run scripts on the host's cron service, not Korta itself.
• Hosts without SSH. Korta needs SSH access to every host it manages.

Next steps

• Install Korta and get started.
• Read the module catalog to see what you can manage.
• Read Korta Enterprise to see the manager.