Moving from nginx or Apache

Most nginx and Apache features have a direct equivalent in Arka, usually shorter. This page gives a safe order of work and translation tables for the directives people use most.

A safe plan#

1. Install Arka next to the old server, so nothing changes for visitors yet. Arka's welcome site wants port 80, which the old server still holds: change /etc/arka/hosts/welcome.toml to listen = [":8080"] and run sudo systemctl restart arka.
2. Write one host file per site (or create them in the panel) with listen = [":8080"] for now. Use the tables below.
3. Test each site against Arka without touching DNS — see the command below.
4. Switch over in a quiet moment: stop the old server (sudo systemctl disable --now nginx), change the hosts to the normal ports (remove the listen lines, add [tls] acme = true), and restart Arka. Arka requests certificates for every site within a minute.
5. Keep the old server installed but stopped for a while. Going back is sudo systemctl stop arka && sudo systemctl start nginx.

Testing a site on Arka while DNS still points at the old server:

curl -sv --resolve example.com:8080:127.0.0.1 http://example.com:8080/

Certificates. Let Arka get its own (acme = true) — it needs port 80 for a minute. Reusing certbot's files in /etc/letsencrypt also works (cert and key under [tls]), but the arka user must be able to read the private key, and certbot's renewals then need systemctl reload arka as a deploy hook.

.htaccess files are not read by Arka. Move their rules into the host file: most WordPress, Laravel and Drupal .htaccess files only send unknown paths to index.php, which is front_controller = "/index.php".

A worked example#

An nginx site with a PHP application, an API behind a proxy and the usual HTTPS redirect:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www/example/public;
    client_max_body_size 32m;
    add_header X-Frame-Options SAMEORIGIN;

    location /api/ {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
    location ~ /\.(?!well-known) { deny all; }
}

The same site in Arka — one file, and the HTTPS redirect, forwarded headers and hidden dotfiles come built in:

# /etc/arka/hosts/example.com.toml
server_names = ["example.com", "www.example.com"]

[tls]
acme = true
redirect_http = true

[limits]
max_body_size = "32MB"

[headers]
security = true            # X-Frame-Options and the other recommended headers

[[routes]]
path = "/api/"
handler = { type = "proxy", upstreams = ["127.0.0.1:3000"], strip_prefix = true, preserve_host = true }

[[routes]]
path = "/"
handler = { type = "fastcgi", address = "unix:/run/php/php8.3-fpm.sock", root = "/var/www/example/public", front_controller = "/index.php", max_conns = 5 }

From nginx#

From Apache#

What is different#

• No inheritance. nginx and Apache settings flow from http to server to location. In Arka each host file is complete on its own; share settings on purpose with snippets.
• No if. Conditions are explicit: when on routes, [[variables]] for computed values, [access] and [geo] for addresses and countries.
• Saving applies. There is no reload step — and a broken file never takes a site down, because its last good version keeps serving.
• Safe defaults. Forwarded headers that visitors cannot forge, retries that never repeat a POST, dotfiles hidden, symbolic links kept inside the site, compression and caching of static files — all without configuration.