---
title: "Frequently Asked Questions"
description: "Answers to common questions: supported deployments, the upgrade path, tailnet size, SQLite or PostgreSQL, and recovering from an invalid policy."
sidebar:
  label: "FAQ"
---

## What is the design goal of slopscale?

Slopscale aims to implement a self-hosted, open source alternative to the
[Tailscale](https://tailscale.com/) 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](/slopscale/about/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](https://github.com/aislopware/slopscale/milestones).
Have a look at [our current plan](https://github.com/aislopware/slopscale/milestones) 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](/setup/install/official) for more information.

Every release is also published as a [container image](/slopscale/setup/install/container) 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](https://github.com/aislopware/slopscale/discussions).

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

Please follow the steps outlined in the [upgrade guide](/slopscale/setup/upgrade) 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](https://github.com/aislopware/slopscale/blob/main/CHANGELOG.md) 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](/slopscale/setup/backup) 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](/slopscale/ref/integration/reverse-proxy) on how to configure various reverse proxies. Questions go to
[GitHub discussions](https://github.com/aislopware/slopscale/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.

See also https://tailscale.com/docs/concepts/device-visibility.

## 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.

:::warning[Full server configuration required]

The above commands to get/set the policy require a complete server configuration file including database settings. A
minimal config to [control Slopscale via remote CLI](/slopscale/ref/api#remote-control) is not sufficient. You may use
`slopscale -c /path/to/config.yaml` to specify the path to an alternative configuration file.
:::

## 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.

:::warning[Backup and test in a demo environment required]

The commands below update the IP addresses of all nodes in your tailnet and this might have a severe impact in your
specific environment. At a minimum:

- [Create a backup of your database](/slopscale/setup/upgrade#backup)
- Test the commands below in a representive demo environment. This allows to catch subsequent connectivity errors
  early and see how the tailnet behaves in your specific environment.
:::

- Stop Slopscale
- Restore the default prefixes in the [configuration file](/slopscale/ref/configuration):
    ```yaml
    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:
    ```sql
    UPDATE nodes
    SET ipv4=concat('100.64.', id/256, '.', id%256),
        ipv6=concat('fd7a:115c:a1e0::', format('%x', id));
    ```
- Update the [policy](/slopscale/ref/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](https://tailscale.com/docs/features/logging#client-logs) 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](/slopscale/ref/configuration) 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.