Every tool here is good at something, and several are more mature than askd. This page sets out where askd genuinely differs, and where it does not, so you can judge the fit yourself. If you only want the short version, the summary is on the main page.
askd is built from primitives that have already survived the field, deliberately. Single Packet Authorisation has been in production since fwknop shipped it in 2004. Flat CA-signed credentials are the shape Nebula proved. Dial-out tunnels are what Cloudflare Tunnel and Teleport run at scale. Duplicate-send multipath is long-settled practice in SD-WAN and MPTCP. Novelty is a liability in security infrastructure, so every part here is one that has already been attacked by someone else first.
The contribution is the combination, in one small self-hostable binary: an SPA-gated silent port, a dial-out overlay with no inbound port, capability credentials, a relay that is blind to the traffic and to its own audit log, gap-free multipath, and a hardware-rooted CA, with no third-party dependencies and no foreign control plane. Judged as a system rather than feature by feature, that combination is not currently occupied by anything else.
It also holds together better than the parts suggest. Three properties are worth naming, because they are what makes the combination a system rather than a pile of features.
A credential is a small CA-signed object that the relay verifies statelessly against a public key. Nothing is registered in any database. There is no identity provider, no SSO or SAML, no directory, no account store, and nothing to phone home to. The CA vouches once, offline, and from then on the credential is the authorisation. Issue one on an air-gapped machine and it works. The access proxies federate to an external IdP by design, and even self-hosted overlays keep a controller that has to be running and reachable to authorise a connection. askd has nothing to federate to, which is also why there is no account database to breach and no login service to take down.
The trust root is physical, a hardware token or HSM you hold, and the CA key cannot be exported from it. Authorisation is a signed capability naming what may be reached, with a validity window. The reach it grants is address-shaped, a host and port bounded by the gateway's CIDR allowlist, the kind of thing you would normally need an L3 network for. And it is delivered as an ordinary L7 session under stock SSH, with no tun interface, no routes, no address plan and nothing in the kernel. The result is network-shaped reach without operating a network, and one chain from the token in your hand to the byte on the wire rather than four products integrated at the edges.
Because the client owns the session and simply sends it across every relay path at once, failover needs no health checks, no leader election and no reconvergence. A relay dying mid-session costs nothing because the other copies were already in flight, and since each packet counts from whichever copy lands first, the measured latency comes out lower than the best single path. Resilience falls out of the design instead of being bolted onto it.
| askd | Tailscale | Cloudflare | Teleport | WireGuard | fwknop | OpenZiti | |
|---|---|---|---|---|---|---|---|
| No inbound ports | yes | yes | yes | proxy | listens | SPA-gated | yes |
| Silent to probes (SPA) | yes | no | no | no | no | yes | partly |
| Self-hostable control plane | yes | partly | SaaS | yes | yes | local | yes |
| Sovereign (no vendor in the loop) | yes | no | no | partly | yes | yes | yes |
| Jurisdiction (applicable law) | EU | Canada | US | US | no vendor | no vendor | US |
| No middleman reads your traffic | yes | yes | no | no | yes | yes | yes |
| Capability credentials | yes | ACLs | yes | yes | no | no | yes |
| Granular live cut | yes | partly | partly | yes | no | no | yes |
| Hardware-rooted CA | yes | no | no | partly | no | no | partly |
| Runs unprivileged (no root) | yes | partly | yes | no | partly | no | partly |
| Sandboxed by default | yes | no | no | no | no | no | no |
| Gap-free multipath | yes | no | no | no | no | no | partly |
| Third-party dependencies | none | many | SaaS | many | kernel | libs | many |
Blue marks the tools that achieve a row; bold blue is askd. A single table cannot capture nuance, which is what the rest of this page is for.
What is actually exposed, precisely. The machines you are protecting expose nothing. An askd agent opens no port at all, so on the asset itself there is no socket to scan, no service to fingerprint and nothing to attack. The only listening socket in the whole system is the relay's single port, and that port is silent: without a valid signed knock it answers nothing, so a scan learns that something is listening and not one thing more. The knock transport is a deployment choice, not a fixed property of the design: run it over TCP where the network permits only outbound TCP through a proxy, or over UDP where you want no fingerprint at all, since an invalid datagram is dropped before anything answers. TCP is what ships today and UDP is the next transport, with the signed knock already sized to fit a single datagram. You pick whichever the network in front of you allows.
The asymmetry is the entire point. You move the exposed surface off hundreds of assets and onto one or two relays that hold no key, store no secret, read nothing, and can be rebuilt or replaced at will. Compromising a relay yields ciphertext and inconvenience, not access. Two hardened relays are a tractable defensive problem; two hundred internet-reachable sshd instances are not.
Nebula, Tailscale, WireGuard. These build a network; askd brokers access. That is the whole difference, and it cuts both ways.
The closest cousin on the credential model: flat, CA-signed, group-tagged certificates rather than X.509, self-hosted, one static userspace binary. Different layer, though. Nebula is L3, giving every node a stable overlay IP on a tun interface, with nodes hole-punching UDP directly and lighthouses doing discovery.
Where askd differs: it works where hole-punching cannot, on UDP-blocked and egress-only corporate networks; the relay port is SPA-gated and silent rather than a listening UDP endpoint; there is no tun interface, no route table entry, and no kernel involvement; and you grant reach to a service, not L3 access to a whole host.
An honesty note: "our relay is blind" is a win over TLS-terminating proxies, not over Nebula. A Nebula lighthouse never sees your traffic either. Against Nebula the real differentiators are egress survival, SPA invisibility, the absent tun interface, and hardware gating.
WireGuard mesh plus a coordination server, with stable overlay IPs, ACL-scoped visibility and excellent ergonomics.
The trade is the coordination server: a control plane in a foreign jurisdiction that can be revoked, subpoenaed or switched off, which you cannot fully self-host. Headscale recovers much of that, at the cost of running an unofficial control plane.
The crypto floor everything else stands on: kernel-level encrypted tunnels, fully self-hosted, no vendor at all.
It provides no discovery, identity or access-control layer, so you build those yourself, and it listens on a port, so it is visible to a scanner.
Identity provider plus proxy, usually with a SaaS control plane. SSH, Kubernetes, databases and web, with session recording, RBAC and MFA.
The structural trade is that the proxy terminates your traffic to read it. That is not a flaw, it is the requirement: you cannot record a session you cannot decrypt. askd makes the opposite bet, and therefore cannot offer recording at the relay.
The closest architectural peer: open source, outbound-only "dark" services with no inbound port, a self-hostable controller and routers, and application-to-application encryption so its routers stay blind, much like askd's relay.
It is stewarded by a US company, its public routers listen and authenticate with mTLS rather than staying silent until a signed knock, it carries a large dependency graph, and the trust root is not hardware-rooted. askd is the small, sovereign, silent one.
The closest European peer: Berlin-based, BSD-licensed, open, self-hostable and zero-trust, so it matches askd on EU basing and on sovereignty.
The difference is shape. NetBird is a WireGuard mesh you join, and increasingly a managed network you rent. askd is relay-first dial-out that you host anywhere, blind by default, in a sub-1 MB binary with the trust root on a hardware token.
CyberArk, BeyondTrust, Delinea. This is the comparison that most clarifies what askd is, because the two make opposite bets about the middleman.
A PAM holds every privileged credential in a central vault, rotates them so no human knows the password, opens the session on the engineer's behalf, injects the credential, and records every keystroke. To do any of that the broker must see plaintext. It is a deliberate, defensible design: you accept an all-seeing middleman in exchange for control, attestation and recording.
askd inverts it. The relay opens no port, holds no secret, and sees nothing. You get capability-scoped reach and a tamper-evident metadata trail, but no credential vaulting and no session recording, because a blind relay cannot provide them.
If your compliance regime requires a recorded, replayable session, you need a PAM or a platform, not askd. If your requirement is that nobody in the middle can read the session at all, a PAM cannot give you that, and askd can.
The reference SPA implementation, in C, since 2004, widely deployed and actively maintained. askd's knock is the same idea, and fwknop had it first.
The difference is what a successful knock buys. fwknop opens your real firewall to your real service, so after the knock you are talking to sshd directly. askd's knock opens only a blind relay, so even post-knock nobody holds a socket to the target: the machine still has no inbound port. fwknop also needs root to manage the firewall, has no credential model beyond the shared key, and offers no relay, no multipath and no capability scoping.
The two knock transports suit opposite networks. UDP, as fwknop uses it, vanishes entirely from a scan but needs UDP egress. TCP survives the corporate network that permits only outbound TCP through a proxy, which is why askd runs it today. askd treats the transport as pluggable and UDP is the next one, so the deployment picks what its network allows rather than the tool dictating it.
askd is built for a specific shape of problem. It fits when:
If instead you need a full L3 network between many nodes, or recorded and replayable sessions for a compliance regime, that is a different job and a heavier tool does it better. askd stays deliberately small.
Between fwknop, which is a firewall knock and nothing more, and Tailscale or Teleport, which are platforms you adopt wholesale, there is an unoccupied space: an open, self-hostable, dependency-free tool that combines SPA invisibility, a blind dial-out relay, capability credentials and gap-free multipath, sitting underneath stock SSH rather than replacing it.
The two properties that pin it down: askd is the only one here that is both in the path, so it works through hostile egress-only networks where peer-to-peer meshes cannot, and blind, so unlike the proxies that manage the same trick it never reads what it carries. OpenZiti is the only other tool that holds both, and it is a large US fabric rather than a small European binary.
The honest summary: pick askd when you want reachability without a network and without a middleman who can read you, self-hosted, under European law. Pick almost anything else here if you want breadth, maturity, or a product you can buy.