IP Access Restriction¶

By default, your SeaTable Server is accessible from any IP address. This article explains how to limit access to a list of allowed IP addresses (allowlist) or how to block single IP addresses (blocklist). Requests from all other IP addresses are answered with 403 Forbidden.

The restriction is done by Caddy. You don't have to modify seatable-server.yml or caddy.yml. Instead, you add one additional yml file and one file containing your IP addresses. This keeps your changes intact during updates.

Configure an allowlist¶

Step 1: Create the file with your allowed IP addresses¶

Create a new directory caddy-snippets inside /opt/seatable-compose and add a file ip-allowlist.caddy:

mkdir -p /opt/seatable-compose/caddy-snippets
nano /opt/seatable-compose/caddy-snippets/ip-allowlist.caddy

Insert the following content and replace the example IP addresses with your own:

@blocked {
    # Office
    not remote_ip 203.0.113.10
    # VPN gateway
    not remote_ip 198.51.100.0/24
    # Home office (multiple addresses can be separated by spaces)
    not remote_ip 192.0.2.44 192.0.2.45
    # Docker networks, required for components on the same host
    not remote_ip private_ranges
}
handle @blocked {
    respond 403
}

Explanation

• Every line not remote_ip ... accepts one or more IP addresses or CIDR ranges, separated by spaces.
• All lines must match for a request to be blocked. In other words: a request is blocked if its IP address is not part of any line.
• Lines starting with # are comments.
• private_ranges covers all private and loopback networks (e.g. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8). Components like Collabora Online, OnlyOffice, SeaDoc or the Python Pipeline call your SeaTable Server via its public URL. These requests reach Caddy with an internal Docker IP address and would be blocked without this line.

Step 2: Create ip-allowlist.yml¶

Create a new file /opt/seatable-compose/ip-allowlist.yml with the following content:

---
services:
  caddy:
    volumes:
      - ./caddy-snippets:/etc/caddy/custom:ro

  seatable-server:
    labels:
      caddy_0.import: /etc/caddy/custom/ip-allowlist.caddy

This mounts the directory caddy-snippets into the Caddy container and imports your IP list into the configuration of SeaTable Server. Docker Compose merges these settings with caddy.yml and seatable-server.yml.

Step 3: Add ip-allowlist.yml to your .env file¶

ip-allowlist.yml must be the last entry of the COMPOSE_FILE variable inside your .env file:

sed -i "s/COMPOSE_FILE='\(.*\)'/COMPOSE_FILE='\1,ip-allowlist.yml'/" /opt/seatable-compose/.env

Step 4: Apply the changes¶

Run the following command inside /opt/seatable-compose:

docker compose up -d

Check the logs of Caddy for errors:

docker logs caddy 2>&1 | grep -i "invalid block"

Test the restriction¶

Run the following commands from a computer with a non-allowed IP address (e.g. a smartphone hotspot). Replace seatable.example.com with your domain:

curl -s -o /dev/null -w '%{http_code}\n' https://seatable.example.com/
curl -s -o /dev/null -w '%{http_code}\n' https://seatable.example.com/api2/ping/

Both commands must return 403. From an allowed IP address, you get 302 and 200, and SeaTable works as usual.

Restrict additional components¶

Components like Collabora Online or n8n are accessible via their own ports. Each component has its own Caddy configuration, which is not covered by the restriction of SeaTable Server. If you want to restrict these components as well, add their services to ip-allowlist.yml. Please note that these services use the label prefix caddy instead of caddy_0:

---
services:
  caddy:
    volumes:
      - ./caddy-snippets:/etc/caddy/custom:ro

  seatable-server:
    labels:
      caddy_0.import: /etc/caddy/custom/ip-allowlist.caddy

  collabora:
    labels:
      caddy.import: /etc/caddy/custom/ip-allowlist.caddy

  n8n:
    labels:
      caddy.import: /etc/caddy/custom/ip-allowlist.caddy

These are the service names of the components with their own ports:

gatus.yml adds a redirect from /status to the Gatus port. This redirect is executed before the IP check and therefore stays accessible for every IP address. Add the import to the gatus service to protect the status page itself.

Update the list of IP addresses¶

Caddy does not notice changes to ip-allowlist.caddy automatically. After you have changed the file, reload the configuration of Caddy:

docker exec caddy caddy reload --config /config/caddy/Caddyfile.autosave --adapter caddyfile

The reload applies the new list without any interruption. If your file contains an error, the reload is aborted with an error message and the previous configuration stays active.

Alternatively, you can restart Caddy with docker compose restart caddy. This takes a few seconds, your certificates are kept.

Let's Encrypt¶

Let's Encrypt keeps working without any further configuration. Caddy answers the ACME challenges for your certificates before your IP check is executed:

• HTTP-01 challenges on port 80 are answered internally by Caddy. The restriction is only added to the HTTPS configuration.
• TLS-ALPN-01 challenges on port 443 are answered during the TLS handshake, before any HTTP rule is evaluated.

There is no need to open the restriction for the IP addresses of Let's Encrypt.

IPv6¶

If you only allow IPv4 addresses, make sure your domain has no AAAA record. You can check this with:

dig AAAA seatable.example.com +short

If the command returns an IPv6 address, users with IPv4 and IPv6 connect via IPv6. Caddy sees their IPv6 address, which is not on your list, and blocks them. Either remove the AAAA record or add the IPv6 addresses or ranges of your users to ip-allowlist.caddy.

If you use IPv6, IPv6 must be enabled for the Docker network of Caddy. Otherwise, Caddy only sees the IP address of the Docker gateway for every IPv6 request. Read more about this in Activate IPv6.

Configure a blocklist¶

You can also use the opposite approach and block single IP addresses, while all other IP addresses keep access. Remove the not from your ip-allowlist.caddy:

@blocked {
    # Scanner
    remote_ip 203.0.113.10 203.0.113.11
    # Network of a hosting provider
    remote_ip 198.51.100.0/24
}
handle @blocked {
    respond 403
}

In this case, a request is blocked if its IP address matches any of the lines. All other steps are identical.