Frequently Asked Questions

Answers to common questions: supported deployments, the upgrade path, tailnet size, SQLite or PostgreSQL, and recovering from an invalid policy.

What is the design goal of slopscale?

Slopscale aims to implement a self-hosted, open source alternative to the Tailscale control server. Slopscale’s goal is to provide self-hosters and hobbyists with an open-source server they can use for their projects and labs. It implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.

How can I contribute?

Slopscale is “Open Source, acknowledged contribution”, this means that any contribution will have to be discussed with the Maintainers before being submitted.

Please see Contributing for more information.

Why is ‘acknowledged contribution’ the chosen model?

Both maintainers have full-time jobs and families, and we want to avoid burnout. We also want to avoid frustration from contributors when their PRs are not accepted.

We are more than happy to exchange emails, or to have dedicated calls before a PR is submitted.

When/Why is Feature X going to be implemented?

We use GitHub Milestones to plan for upcoming Slopscale releases. Have a look at our current plan to get an idea when a specific feature is about to be implemented. The release plan is subject to change at any time.

If you’re interested in contributing, please post a feature request about it. Please be aware that there are a number of reasons why we might not accept specific contributions:

It is not possible to implement the feature in a way that makes sense in a self-hosted environment.
Given that we are reverse-engineering Tailscale to satisfy our own curiosity, we might be interested in implementing the feature ourselves.
You are not sending unit and integration tests with it.

Do you support Y method of deploying slopscale?

We currently support deploying slopscale using our binaries and the DEB packages. Visit our installation guide using official releases for more information.

Every release is also published as a container image at ghcr.io/aislopware/slopscale, the same binary in a minimal image, which is how the server is run most often. Questions about a particular orchestrator go to GitHub discussions.

What is the recommended update path? Can I skip multiple versions while updating?

Please follow the steps outlined in the upgrade guide to update your existing Slopscale installation. Its required to update from one stable version to the next (e.g. 0.34.0 → 0.35.0 → 0.36.0) without skipping minor versions in between. You should always pick the latest available patch release.

Be sure to check the changelog for version specific upgrade instructions and breaking changes.

How many clients does Slopscale support?

Slopscale is built for a person, a lab or a small organisation, but it is measured as it is built. The cost that matters is the map of who may talk to whom: a change that touches it (a machine joining or leaving, a tag, a route, a share, an approval or a policy edit) recomputes it, and every connected machine receives a new map response. Anything else a machine reports (its endpoints, its relay, its last-seen time) carries the previous map forward and reaches peers as a small patch, or is stored without a broadcast when no peer reads it.

A tailnet of a thousand machines that rarely change is comfortable. A tailnet of a few hundred laptops and phones that move all day is comfortable too, because moving is not a map change. The two together, many machines and frequent membership or policy changes, is where CPU time goes, and the server’s slopscale_mapper_* and slopscale_mapresponse_* metrics show it.

Which database should I use?

SQLite is the default and the one most installations run:

It needs no other service and lives in one file.
It is compiled into the binary and hardened (defensive mode, no double-quoted strings).
Backup and restore go through SQLite itself, so a backup can be taken while the server runs.

PostgreSQL is supported the same way: every migration and the whole test suite run against both, and the same queries reach both through one query builder, so there is no feature the one has and the other lacks. Pick it when you already run PostgreSQL and want it backed up, replicated and monitored with the rest.

The slopscale project does not provide a tool to migrate from one to the other.

Why is my reverse proxy not working with slopscale?

We don’t know. We don’t use reverse proxies with slopscale ourselves, so we don’t have any experience with them. We have community documentation on how to configure various reverse proxies. Questions go to GitHub discussions.

Can I use slopscale and tailscale on the same machine?

Running slopscale on a machine that is also in the tailnet can cause problems with subnet routers, traffic relay nodes, and MagicDNS. It might work, but it is not supported.

Why do two nodes see each other in their status, even if a policy rule allows traffic only in one direction?

A frequent use case is to allow traffic only from one node to another, but not the other way around. For example, the workstation of an administrator should be able to connect to all nodes but the nodes themselves shouldn’t be able to connect back to the administrator’s node. Why do all nodes see the administrator’s workstation in the output of tailscale status?

This is essentially how Tailscale works. If traffic is allowed to flow in one direction, then both nodes see each other in their output of tailscale status. Traffic is still filtered according to the policy, with the exception of tailscale ping which is always allowed in either direction.

My policy is stored in the database and Slopscale refuses to start due to an invalid policy. How can I recover?

Slopscale checks if the policy is valid during startup and refuses to start if it detects an error. The error message indicates which part of the policy is invalid. Follow these steps to fix your policy:

Dump the policy to a file: slopscale policy get --bypass-server-and-access-database-directly > policy.json
Edit and fixup policy.json. Use the command slopscale policy check --file policy.json to validate the policy.
Load the modified policy: slopscale policy set --bypass-server-and-access-database-directly --file policy.json
Start Slopscale as usual.

How can I migrate back to the recommended IP prefixes?

Tailscale only supports the IP prefixes 100.64.0.0/10 and fd7a:115c:a1e0::/48 or smaller subnets thereof. The following steps can be used to migrate from unsupported IP prefixes back to the supported and recommended ones.

Stop Slopscale

Restore the default prefixes in the configuration file:

prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

Update the nodes.ipv4 and nodes.ipv6 columns in the database and assign each node a unique IPv4 and IPv6 address. The following SQL statement assigns IP addresses based on the node ID:
```
UPDATE nodes
SET ipv4=concat('100.64.', id/256, '.', id%256),
    ipv6=concat('fd7a:115c:a1e0::', format('%x', id));
```
Update the policy to reflect the IP address changes (if any)
Start Slopscale

Nodes should reconnect within a few seconds and pickup their newly assigned IP addresses.

How can I avoid to send logs to Tailscale Inc?

A Tailscale client collects logs about its operation and connection attempts with other clients and sends them to a central log service operated by Tailscale Inc.

Slopscale, by default, instructs clients to disable log submission to the central log service. This configuration is applied by a client once it successfully connected with Slopscale. See the configuration option logtail.enabled in the configuration file for details.

Alternatively, logging can also be disabled on the client side. This is independent of Slopscale and opting out of client logging disables log submission early during client startup. The configuration is operating system specific and is usually achieved by:

setting the environment variable TS_NO_LOGS_NO_SUPPORT=true or
by passing the flag --no-logs-no-support to tailscaled or
by disabling “Remote client logging” in the mobile app settings

See https://tailscale.com/docs/features/logging#opt-out-of-client-logging for details.