Secure Guest Access to a Zensical Server Using Tailscale

Overview

Assume the Zensical documentation server is running on a Debian OVH server and is normally reachable only through Tailscale. There are four practical ways to provide guest access, ranging from fully private Tailscale access to ordinary browser-only access.

The main tradeoff is between security/control and guest convenience.

1. Full Tailscale installation with device sharing

In this approach, the guest installs Tailscale and signs into their own Tailscale account. You share only the Debian OVH machine hosting Zensical rather than inviting the guest into your entire tailnet.

Tailscale says a shared machine is visible only to the specific recipient and does not expose the rest of your tailnet. Shared devices are also quarantined so they cannot initiate arbitrary connections back into the recipient's network. Access can be further constrained through policy. Tailscale

Advantages

• Strongest isolation of the four approaches.
• Zensical never needs to be exposed to the public Internet.
• Access is associated with a specific Tailscale identity.
• Easy to revoke access.
• Traffic remains within Tailscale's encrypted networking model.
• Can restrict the guest to only the Zensical server and potentially only port 8000.
• No need to configure public DNS, TLS certificates or router/firewall port forwarding.
• Excellent choice for repeated access by a colleague or collaborator.

The connection is essentially:

text Guest computer | | Tailscale encrypted network | v OVH Debian server 100.101.112.116:8000 | v Zensical

Disadvantages

• The guest must install Tailscale.
• The guest needs a Tailscale identity/account.
• Slightly more onboarding than simply sending a web link.
• Device sharing gives access to the machine rather than inherently limiting the guest to one web application, so policy should be used if strict port-level isolation matters.

Best suited for

Known collaborators who will access the documentation more than once and who don't object to installing Tailscale.

Security: Excellent
Guest convenience: Good
Administration: Easy

2. Tailscale Funnel

Funnel publishes a service running on a Tailscale machine to the Internet through an HTTPS *.ts.net address. The visitor does not need Tailscale installed. Tailscale

For example, Zensical might continue to run internally on:

text localhost:8000

while Funnel presents something similar to:

text https://docs-server.example-tailnet.ts.net

The topology becomes:

text Guest browser | | HTTPS / Internet v Tailscale Funnel | | encrypted proxy v OVH Debian | v Zensical :8000

Funnel terminates HTTPS and can reverse-proxy traffic to the local Zensical service. Tailscale currently restricts Funnel's public listening ports to 443, 8443, and 10000; the backend application can still run on another local port such as 8000. Tailscale

Advantages

• Guest requires only a browser.
• No Tailscale installation.
• No Tailscale account required for the visitor.
• Very quick to turn on and off.
• Automatically provides HTTPS.
• Does not expose the OVH server's public IP directly to the guest.
• Excellent for short demonstrations or temporary document review.

Disadvantages

The biggest issue is authorization.

A standard Funnel URL is reachable by anyone who has or discovers the URL. Funnel itself is exposing the service to the public Internet rather than authenticating a particular guest. Tailscale explicitly distinguishes this from device sharing. Tailscale

Other disadvantages include:

• Not identity-specific by itself.
• URL possession becomes an important part of your security.
• Less appropriate for confidential material without an additional authentication layer.
• Funnel currently has bandwidth limitations.
• Requires Funnel, MagicDNS and HTTPS support to be enabled for the tailnet. Tailscale
• Funnel remains a beta feature according to current Tailscale documentation. Tailscale

Best suited for

Short-lived sharing of non-sensitive documentation, demos, test sites or material you would not be concerned about someone accessing if the URL leaked.

Security: Moderate
Guest convenience: Excellent
Administration: Very easy

3. Tailcat

Tailcat takes a substantially different approach.

It uses pieces of Tailscale's open-source data plane—WireGuard encryption, NAT traversal and DERP fallback—but does not require the normal Tailscale control plane or a conventional tailnet membership.

Tailscale describes it as roughly analogous to netcat transported over Tailscale's networking technology. Tailscale

A conceptual deployment would be:

text Guest PC | | Tailcat client | | WireGuard / NAT traversal / DERP v Tailcat listener OVH Debian server | v Zensical :8000

Advantages

• No need to add the guest to your tailnet.
• Does not require exposing Zensical as an ordinary public web service.
• Uses WireGuard-based encrypted transport.
• Good for short-lived, point-to-point access.
• Particularly attractive for technically sophisticated users.
• Avoids much of the account/control-plane overhead of a normal Tailscale deployment.
• Can be useful for temporary SSH, TCP services, development servers and similar scenarios.

Disadvantages

• The guest still has to install or run Tailcat.
• It is predominantly a command-line-oriented tool rather than an end-user browser-access product.
• Less convenient for nontechnical guests.
• You lose much of what makes normal Tailscale administration attractive:
• central user identity
• normal tailnet ACL management
• device administration
• conventional sharing controls
• richer auditing and lifecycle management.
• Access credentials/connection information must be treated as secrets.
• Tailcat is much newer than the established Tailscale client and sharing model. Tailscale introduced it publicly in August 2026. Tailscale

Best suited for

Developers, administrators and technically comfortable users who need temporary encrypted access without becoming members of your tailnet.

It is probably not the best option for someone whose requirement is simply:

"Send me a link so I can read your documentation."

Security: Very good when configured correctly
Guest convenience: Fair to poor
Administration: Moderate

4. Browser-only access through an authenticated reverse proxy

This is the most interesting alternative when the requirement is:

The guest should install nothing, but access should still require authentication.

Instead of exposing the Zensical development server directly, you put a web server such as Caddy or nginx in front of it.

For example:

text Internet | | HTTPS v Caddy / nginx | | authentication v Zensical localhost:8000

The guest might visit:

text https://docs.example.com

and be prompted for credentials.

Zensical itself can remain bound only to:

text 127.0.0.1:8000

which means it isn't directly reachable from the Internet at all.

The proxy becomes the only Internet-facing component.

Simple username/password version

Both nginx and Caddy support HTTP Basic Authentication. nginx provides its auth_basic mechanism, while Caddy provides basic_auth; Caddy requires passwords to be stored as hashes rather than plaintext. Nginx

A guest experience could therefore be:

```text Guest opens:

https://docs.example.com

    ↓

Username: guest1 Password: **

    ↓

Zensical documentation ```

Advantages

• No software installation for the guest.
• No Tailscale account required.
• Works on essentially any normal browser.
• Access can be revoked by disabling the user's credentials.
• Can provide HTTPS and normal domain names.
• Can support multiple independent guest accounts.
• Easy to place additional security controls in front of Zensical.
• Caddy in particular makes reverse proxying quite concise. It has first-class reverse_proxy, basic_auth, and forward_auth capabilities. Caddy Web Server

Disadvantages

• The proxy is publicly reachable.
• You now have a public Internet service to maintain and patch.
• Requires more setup than Funnel.
• Usually requires DNS configuration.
• Firewall configuration must be correct.
• Password management becomes admin responsibility.
• Basic Authentication should never be used over unencrypted HTTP; it needs HTTPS. Caddy explicitly warns about this. Caddy Web Server
• Brute-force protection, logging and account lifecycle deserve consideration if the service becomes permanent.

More sophisticated authentication

The proxy doesn't have to use simple usernames and passwords.

You can put an authentication service in front of Zensical and provide:

• one-time codes
• OAuth
• Google/Microsoft sign-in
• passkeys
• multi-factor authentication
• identity-provider integration.

Caddy, for example, supports a forward_auth mechanism designed to hand authentication to an external identity gateway before proxying the request to the application. Caddy Web Server

That leads to an architecture such as:

text Guest browser | | HTTPS v Caddy | +----> Authentication service | | | approved | | <------------+ | v Zensical 127.0.0.1:8000

Best suited for

People who should receive controlled access but who cannot or do not want to install Tailscale.

For a long-lived externally accessible documentation system, this can be preferable to Funnel.

Security: Very good if configured properly
Guest convenience: Excellent
Administration: Moderate to high

Overall comparison

Recommendation for your OVH/Zensical environment

It's probably better to treat these deployment options as four levels of access, rather than competing solutions.

For regular collaborators, continue using ordinary Tailscale. Zensical can remain completely private:

text Windows ↓ Tailscale ↓ 100.101.112.116:8000 ↓ Zensical

For a known collaborator, use Tailscale device sharing. This gives the strongest combination of identity, privacy and easy revocation without putting the service on the public Internet. Tailscale

For a quick demonstration, use Funnel. It can be turned on, with an HTTPS URL sent to the user allowing them to view the material, after which Funnel can be turned off, releasing the connection. This should be reserved for material that isn't highly sensitive because the Funnel endpoint itself isn't guest-authenticated. Tailscale

For technical short-term connections, Tailcat is interesting and worth documenting, but shouldn't be deployed as the normal way people consume the documentation. Its strength is lightweight encrypted point-to-point connectivity rather than frictionless browser publishing. Tailscale

For nontechnical guests who need secure browser-only access, the best option is Caddy + authentication. In fact, for our documentation server, Caddy rather than nginx should be implemented because a small Zensical installation can be configured with comparatively little machinery:

text Regular user | Tailscale | v +----------------+ | OVH Debian | | | Internet ---------->| Caddy | guest | | | | authentication| | | | | v | | Zensical | | localhost:8000 | +----------------+

That would let us retain private Tailscale access for collaborators while selectively offering an authenticated HTTPS entrance to outside guests.

For the documentation server we're building, consider the following priority sequencing:

1. Tailscale device sharing — preferred whenever the guest will install Tailscale.
2. Caddy + authentication — preferred browser-only solution for controlled access.
3. Funnel — excellent for quick, disposable sharing.
4. Tailcat — excellent technology, but more appropriate for technical point-to-point access than ordinary documentation readers.

The above options (or a subset) would give us a surprisingly flexible documentation platform: the same Zensical instance can remain private by default while supporting several different sharing models depending upon who needs access.