I found Nebula at first. It works well, requiring no central server or public SSL certificate.

Conversely admins need to sign and distribute their own certificates with nebula-cert, and they are used to authorize and encrypt connections.

The minimal requirement to run a Nebula network is a machine with a public, static IP and a port available (a cheapest VPS would work). This machine will serve as a “lighthouse” which other nodes use to find each other. You can have multiple lighthouses and the network is available with at least one of them online, which is handy during migration.

Nebula will try its best at NAT traversal, but if that fails it try to relay connections through nodes configured to work as relays. I simply use lighthouses as relays because they are accessible from every node.¹ A simple (NixOS-based, check official docs for regular ones) lighthouse configuration looks like this:

services.nebula.networks."<name>" = {
  ca = "/etc/nebula/ca.crt";        # it would be better to use agenix or sops-nix
  cert = "/etc/nebula/host.crt";    # but I'm too lazy to touch a working config
  key = "/etc/nebula/host.key";
  isLighthouse = true;
  isRelay = true;
  listen.port = 4242;
};

networking.firewall = {
  allowedTCPPorts = [ 4242 ];
  allowedUDPPorts = [ 4242 ];
};

And a client configuration is a bit more complicated than that, because it needs to know where to find a lighthouse, and to configure its firewall² to accept connections.

services.nebula.networks."<name>" = {
  ca = "/etc/nebula/ca.crt";
  cert = "/etc/nebula/host.crt";
  key = "/etc/nebula/host.key";
  staticHostMap = {
    # nebula ip is the one you assigned to the machine while signing its cert.
    # you can check it with `nebula-cert print -path host.crt`
    "<lighthouse-nebula-ip>" = [ "<lighthouse-public-address>:<port>" ];
  };
  lighthouses = [ "<lighthouse-nebula-ip>" ];
  relays = [ "<lighthouse-nebula-ip>" ];
  # I only have trusted devices in the network,
  # if that's not true use a more strict config
  firewall = let any = [{
    host = "any";
    port = "any";
    proto = "any";
  }]; in {
    inbound = any;
    outbound = any;
  };
};

networking.firewall = {
  allowedTCPPorts = [ 4242 ];
  allowedUDPPorts = [ 4242 ];
};

The mobile app works similarly, just set the same information up with the GUI. Beware that the mobile client doesn’t allow any inbound connections and the firewall is not configurable as of now (2025-07).

Tailscale solves the problems coming with Nebula, at the expense of a central server, and additionally requiring a valid SSL certificate. Normally their clients connect to the Tailscale coordination server to give a smooth onboarding experience, but I don’t want to depend on freemium services, and they do mess up sometimes. Luckily there’s a self-hosted solution called Headscale for personal use scenarios.

In Tailscale, the coordination server is not a regular node anymore. It is a dedicated public service that handles not only service discovery, but also client registration, key distribution and access control. And relays (DERP servers) are a standalone service that can be hosted separately from the coordination server. Headscale is a coordination server implementation that has simplified access control and account system, with an embedded DERP server.

To run Headscale with embedded DERP server^{1 2} (again in NixOS, refer to official docs otherwise):

services.headscale = {
  enable = true;
  address = "0.0.0.0"; # this is the listen address
  settings = {
    server_url = "<public-url-of-the-server>";
    derp = {
      server = {
        enabled = true;
        region_id = 999;
        region_code = "hsc";
        region_name = "Headscale embedded";
        stun_listen_addr = "<listen-addr>:<listen-port>";
        ipv4 = "<public-ipv4-addr>";
      };
      urls = []; # this disables DERP servers provided by Tailscale
    };
    # set these if you don't acquire certs with headscale
    # note you may also want to set `services.headscale.group` to access certs
    tls_cert_path = "<tls-cert>";
    tls_key_path = "<tls-key>";
    dns = {
      # note that this shouldn't be the same as your server's public domain
      # I use an nonexistent TLD like .tail
      base_domain = "<magic-dns-domain>";
    };
  };
};

This is a very basic config, so you may want to checkout the reference config file for more options available.

Once the Headscale service is up and running you need to first set it up.

headscale users create <user-name>

This user name is required in following auth process of clients.

In contrast it’s much simpler to register and run a Tailscale client. The vanilla client is FOSS so I can just go with it:

services.tailscale = {
  enable = true;
  openFirewall = true;
  extraUpFlags = [
    "--login-server"
    "<your-headscale-address>"
  ];
  extraDaemonFlags = [
    "--no-logs-no-support" # this disables telemetry
  ];
  # this configures your system to be able to serve as an exit node
  # (with `sudo tailscale set --advertise-exit-node`,
  # or put `--advertise-exit-node` in `extraSetFlags`)
  useRoutingFeatures = "server";
  # see below
  authKeyFile = "<auth-key>";
};

# prevent tailscale from using nebula interface
systemd.services.tailscaled.serviceConfig = {
  RestrictNetworkInterfaces = "lo <interfaces-other-than-nebula>";
};

This needs some explanation. Basically with this config, Nix generates a systemd service, that starts Tailscale daemon with tailscaled --no-log-no-support <other-flags-omitted> then calls tailscale up once with the given auth key. Some intervention is needed because Tailscale doesn’t avoid Nebula interfaces and this may lead to various issues (Nebula is smart enough to avoid routing through Tailscale so the reverse doesn’t hold).

There are two flows to register a new client with Headscale (official docs here).

1. Non-interactively with a pre-generated key:

   # on the server
   headscale preauthkeys create --user <user-name>
   

   This generates a one-time key that you can put in aforementioned authKeyFile (effective for one hour by default). Deploy the config with the key on your device to log it into the network.

2. Interactively without setting the key:

   # on the client device
   tailscale login --login-server <user-name>
   

   This leads to a web page on the server that shows a key, then you need to register the client with the key.

   # on the server
   headscale nodes register --user <user-name> --key <key-on-the-page>
   

In both cases you only need to do this once per client/device.

On mobile devices it’s even simpler, you need to go out of the way to set your login server but that’s basically it. Upon first login the interactive login page shows up with the key, and again you run headscale nodes register to register the device.

security.acme.acceptTerms = true;
security.acme.certs."<your-domain>" = {
  email = "<your-email>";
  dnsProvider = "<dns-provider>";
  # agenix path to the systemd environmentFile in my case,
  # free to use all other means to provide access keys
  environmentFile = config.age.secrets.acme-env.path;
};

services.headscale = {
  # choose a atypical port
  port = 11366;
  # other options stays the same, omitted
  settings = {
    server_url = "https://<your-domain>:11366";
    derp = {
      server = {
        # anything different from the headscale server port
        stun_listen_addr = "0.0.0.0:11367";
        # ...
      };
    # ...
  };
};

# Also open the corresponding ports in firewall!

Occasionally I run a Windows VM inside my Linux laptop. I need to access it remotely as well. Luckily enough, a tunnel to the virtual machine network can be opened with a one-liner using SSH:

ssh -L 3389:192.168.122.84:3389 <device-running-vm>

This maps 192.168.122.84:3389 (IP address of the virtual machine in my case, and the default port of Microsoft RDP service) on the remote host to localhost:3389. An RDP client can then connect to 127.0.0.1 to access the remote virtual machine. This time I can just use the Microsoft RDP client on mobile to log in.

Why Fennel? Because Lua is too verbose to my taste. And among the alternatives, Fennel

• ships with many syntax sugars and concise syntax forms.
  • Tables get much shorter!
• is a Lisp.
  • S-expressions.
  • Expression-based syntax.
  • Macros.
• has a near one-to-one mapping to Lua.

For instance:

{
  config = function()
    if vim.o.columns < 60 then
      return "short"
    else
      return "full"
    end
  end
}

in Lua is

{:config #(if (< vim.o.columns 60)
              "short"
              "full")}

in Fennel. Now you can see the benefits, as I have many similar cases in my actual config.

I use a little plugin called nfnl¹, which automatically compiles Fennel code to Lua on save.

After installing the plugin, a Neovim config in Fennel is as simple as:

# in the config directory
# you can also use an empty file, which saves you from future permission prompts
echo {} > .nfnl.fnl
nvim init.fnl

Upon saving, nfnl will generate init.lua from init.fnl (it won’t override pre-existing files though). If you are migrating from a Lua-based config, you may find it easier to write an init_.fnl and check the compiled Lua before swapping it in place. It’s rather trivial to write Fennel code equivalent to Lua, so it won’t take long after you get used to the language. And the generated file is decently readable, so check it out when in doubt.

Since this plugin compiles Fennel to Lua ahead of time, it’s not needed to load a config developed with it. Actually there’s no need to load it at all in filetypes other than Fennel. In my config with lazy.nvim I wrote:

[{1 "Olical/nfnl" :ft "fennel"}]

And it works as intended. Neovim gets its Lua, I get my Fennel and they lived happily thereafter.

Fennel itself already ships with many useful macros and forms. But I still find them not covering some pain points of mine. So here is my secret sauce. Bon appétit!

(fn | [& args]
  (let [len (length args)]
    (table.move args 1 (- len 1) 1 (. args len))))

(| 1 2 3 {:a 4 :b 5})

{1, 2, 3, a = 4, b = 5}

require("plugin").setup({ ... })

f(a).b(x).c

(. ((. (f a) :b) x) :c)

;; with threading macros (no placeholders)
(-> ((-> (f a) (. :b)) x)
    (. :c))

;; with SRFI-197 `chain` style macros
(chain (f a)
  (. _ :b)
  (_ x)
  (. _ :c))

;; what if...?
(dot (f a) (b x) c)

(fn dot [x & args]
  (fn transform [x form]
    (case form
      ;; (dot x y) => (. x "y")
      (where form (sym? form)) `(. ,x ,(tostring form))
      ;; bonus rule: (dot x [y z]) => (. x y z)
      (where exprs (sequence? exprs)) `(. ,x ,(unpack exprs))
      ;; (dot x (f a)) => ((. x "f") a)
      [symbol & rest] `((. ,x ,(tostring symbol))
                        ,(unpack rest))
      ;; (dot x ()) => (x)
      [] `(,x)))
  (case args
    ;; (dot x form rest ...) => (dot (dot x form) rest ...)
    [form & rest] (dot (transform x form) (unpack rest))
    ;; (dot x) => x
    [] x))

(dot (require :plugin) (setup {}))

Note that macros presented in this section are assumed to be in Fennel macro modules, defined as fn and imported with import-macros. Additionally, due to the compilation mechanism of nfnl, macro modules need to have a special header like

;; [nfnl-macro]

at top of the file. See its README for this nfnl-specific detail.