Arka documentation

Arka is a web server, reverse proxy and control panel in one program. It serves static sites, PHP applications and anything that speaks HTTP, gets HTTPS certificates by itself, keeps attackers out with a built-in firewall, and lets you see and change every site from your browser.

These pages cover everything from the first install to running hundreds of sites in production. If you are new, read them in order; if you know what you are looking for, jump straight in.

What Arka is#

Arka does the jobs that usually take several programs on a server:

Job Usually done by In Arka
Serve websites and files nginx, Apache, Caddy Built in: static files from memory, compression, HTTP/2 and HTTP/3
Pass requests to applications nginx, HAProxy, Traefik Built in: load balancing, health checks, retries, caching, WebSockets, gRPC
Run PHP nginx + php-fpm, Apache + mod_php Built in FastCGI client for php-fpm
HTTPS certificates certbot, acme.sh Built in: certificates from Let's Encrypt (or any ACME CA) requested and renewed automatically
Web application firewall ModSecurity, Cloudflare Built in, at the protection level you choose: Arka's own fast rules, or the complete OWASP Core Rule Set 4 — uploads and large bodies inspected before they reach your app, a day of learning before it blocks, one-click exceptions
Block repeat attackers fail2ban, CrowdSec Built in: automatic bans, refused before the TLS handshake
Sign-in in front of sites oauth2-proxy, Authelia Built in: OpenID Connect, LDAP, basic auth, JWT, forward auth
A web interface to manage it all cPanel, Plesk, Nginx Proxy Manager Built in: the control panel, with accounts, roles, an audit log, backups and restores
Log rotation and alerts logrotate, monitoring scripts Built in: logs rotated and compressed, a disk reserve, alerts to a webhook when certificates, upstreams or disks need a person

It is a single program written in Rust, a language that rules out the memory-safety bugs behind many web-server vulnerabilities. It runs one event loop per CPU core, the way nginx does.

How Arka is organised#

Arka reads plain-text TOML files. There are four kinds, kept deliberately apart:

File What it holds
/etc/arka/arka.toml How the server process runs: workers, timeouts, the control panel, certificates, updates. Never a website.
/etc/arka/hosts/<id>.toml One complete website ("host"): its names, ports, HTTPS, routes and security. Nothing is inherited from other files.
/etc/arka/streams/<id>.toml One TCP or UDP service passed through Arka: a database, a mail server, a game server.
/etc/arka/snippets/*.toml Pieces that several hosts share on purpose, pulled in with include.

Because each site lives in its own file, a mistake in one site never affects another. If you save a broken file, Arka keeps serving that site's last good version and tells you exactly which line is wrong. Changes take effect in about two milliseconds, without a restart and without dropping a single connection.

You can edit these files by hand, or never see them at all: every setting has a form in the control panel, and the panel keeps your comments and layout when it saves.

Words used in these pages#

Word Meaning
Host One website, described by one file in hosts/. A host can answer to several domain names.
Route A rule inside a host that sends some paths (/api/, /blog/, /) to a handler. Routes match like nginx location blocks.
Handler What a route does with a request: serve files (static), pass it to an application (proxy), run PHP (fastcgi), redirect it, answer it directly, run a script, or serve a WebDAV share.
Upstream An application server Arka passes requests to, such as gunicorn on 127.0.0.1:8000.
Worker One of Arka's threads; there is one per CPU core, each serving connections on its own.
Panel The control panel, on port 9898 by default.

Something missing or unclear? Write to contact@vulntech.com.