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.