{"title":"Self-Hosted ntfy And The Shared IPv6 Quota Behind My 429s","html_url":"https://deallocatedobjects.com/posts/self-hosted-ntfy-and-the-shared-ipv6-quota-behind-my-429s","source_url":"","markdown_content":"My server sends push notifications to my phone when something needs a look: memory running low, a process that stopped answering on its port, a nightly job that failed. For a long time those went through [ntfy](https://ntfy.sh), which is about the nicest way there is to get a message from a shell script onto a phone. You POST some text to a URL and your phone buzzes:\n\n```bash\ncurl -d \"Backup job failed\" https://ntfy.sh/your-alert-topic\n```\n\nThen one day every alert started coming back `429 Too Many Requests`. Nothing on my side had changed, and the same request from my Mac went through fine.\n\n### What ntfy.sh Counts\n\nntfy.sh is free and has no accounts for publishing, so its limits are per visitor, and a visitor is an IP address. The [publishing docs](https://docs.ntfy.sh/publish/#limitations) list the daily cap: \"On ntfy.sh, the daily message limit is 250.\"\n\nThe detail that matters is how ntfy treats IPv6. From the [server config docs](https://docs.ntfy.sh/config/#ipv6-considerations):\n\n> By default, rate limiting for IPv6 is done using the `/64` subnet of the visitor's IPv6 address. This means that all visitors in the same `/64` subnet are treated as one visitor.\n\nThat's a sensible default. Home internet providers routinely hand each customer a /64 or bigger, so counting single IPv6 addresses would let anyone dodge the limit by rotating through their own block. An IPv4 address, on the other hand, counts on its own (`visitor-prefix-bits-ipv4` defaults to 32).\n\n### Where The /64 Comes From\n\nCloud providers don't always work like home providers. DigitalOcean's [IPv6 limits page](https://docs.digitalocean.com/products/networking/ipv6/details/limits/) says a droplet gets \"a maximum of 16 addresses (a subnet mask of `/124`)\". The interface itself is configured with a /64 prefix, but my droplet only owns 16 addresses inside it. The rest of that /64 belongs to other droplets.\n\nSo from ntfy.sh's point of view, my server and every other droplet in that /64 that talks to ntfy.sh are one visitor sharing one 250 message budget. That shared budget was empty, and my alerts were getting turned away with it.\n\nOver IPv4, my server is the only one on its address. When a host has both an IPv6 and an IPv4 address and the server can reach both, `curl` tries IPv6 first, so every alert had been going out over the shared one.\n\n### Checking It Yourself\n\nntfy.sh will tell you how it sees you. `GET /v1/account` without credentials describes the anonymous visitor you're being counted as, including messages sent and remaining today. Ask once over each address family and compare:\n\n```bash\ncurl -6 -s https://ntfy.sh/v1/account | jq '.limits.basis, .stats'\ncurl -4 -s https://ntfy.sh/v1/account | jq '.limits.basis, .stats'\n```\n\n`basis` comes back as `\"ip\"`, and `stats.messages_remaining` is the number to look at. If the IPv6 line is at zero while you've barely sent anything, you're sharing a /64. The daily counter resets at midnight UTC.\n\n### The Quick Fix: curl -4\n\nThe fastest fix is one flag. `-4` makes curl resolve and connect over IPv4 only:\n\n```bash\ncurl -4 -d \"Backup job failed\" https://ntfy.sh/your-alert-topic\n```\n\nWhen I tested it, the same request that got a 429 over IPv6 got a 200 over IPv4. If you use ntfy.sh from a cloud server and want alerts back in five minutes, that's the change to make.\n\nIt only covers the senders you remember to change, though. Anything else on the server that talks to ntfy.sh (a cron job, an app's own notification code, a library with its own HTTP client) still spends from whichever budget it lands on, and your important alerts share both budgets with all of it. I wanted my alerts to stop depending on a free public quota at all.\n\n### Running My Own ntfy\n\nntfy is a single Go binary with an official apt repository, and it's the same open-source server that ntfy.sh runs. I installed the package, which comes with a systemd unit and an `ntfy` user, and kept it on loopback behind nginx. The config that matters, from `/etc/ntfy/server.yml`:\n\n```yaml title=\"/etc/ntfy/server.yml\"\nbase-url: \"https://ntfy.example.com\"\nlisten-http: \"127.0.0.1:2586\"\nbehind-proxy: true\n\n# Nothing is readable or writable without a user or token.\nauth-file: \"/var/lib/ntfy/user.db\"\nauth-default-access: \"deny-all\"\nenable-signup: false\nenable-login: true\nrequire-login: true\n\n# Keep messages for 48 hours so the phone can catch up after being offline.\ncache-file: \"/var/cache/ntfy/cache.db\"\ncache-duration: \"48h\"\n\n# iOS instant delivery (more on this below).\nupstream-base-url: \"https://ntfy.sh\"\n\n# Scripts on the server publish over loopback and skip the request limit.\nvisitor-request-limit-exempt-hosts: \"127.0.0.1,::1\"\n```\n\n`auth-default-access: \"deny-all\"` is the line that makes it private. Out of the box ntfy lets anyone read and write any topic, which is how ntfy.sh works and why its topic names have to be hard to guess. With `deny-all`, an unknown topic is closed to everyone until you grant access to it.\n\n`behind-proxy: true` tells ntfy to take the client's address from `X-Forwarded-For`. Without it, every request arrives from nginx's 127.0.0.1 and every phone and browser gets rate limited as one visitor.\n\n### Users And Tokens\n\nI made three users with the `ntfy` CLI, each with only what it needs:\n\n```bash\nsudo -u ntfy ntfy user add --role=admin admin-user\nsudo -u ntfy ntfy user add publisher\nsudo -u ntfy ntfy user add phone\n\nsudo -u ntfy ntfy access publisher your-alert-topic write-only\nsudo -u ntfy ntfy access phone your-alert-topic read-only\n\nsudo -u ntfy ntfy token add --label=server-alerts publisher\n```\n\nThe scripts on the server never use a password. They use an access token (`tk_...`) for the `publisher` user, which can post to the alert topic and can't read anything. The phone signs in as `phone`, which can read the topic and can't post. If either credential leaks, the damage stops at that one ability on that one topic.\n\nThe token lives in a small env file owned by root, with a group for the accounts allowed to send alerts, mode 0640. `ntfy user add` reads the password from the `NTFY_PASSWORD` environment variable if it's set, so it never has to show up in a command line.\n\n### The nginx Side\n\nnginx terminates TLS and passes everything to the loopback port:\n\n```nginx title=\"/etc/nginx/sites-available/ntfy.example.com\"\nserver {\n listen 443 ssl;\n server_name ntfy.example.com;\n access_log off; # topic names are in the URLs\n\n location / {\n proxy_pass http://127.0.0.1:2586;\n proxy_http_version 1.1;\n proxy_buffering off; # streaming subscriptions\n proxy_set_header Host $http_host;\n proxy_set_header Upgrade $http_upgrade; # WebSocket subscriptions\n proxy_set_header Connection \"upgrade\";\n proxy_set_header X-Forwarded-For $remote_addr;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_read_timeout 3m;\n }\n}\n```\n\nTwo lines are easy to get wrong. `proxy_buffering off` matters because the web app and some clients hold a connection open and stream messages as they arrive, and a buffering proxy sits on them. And `X-Forwarded-For $remote_addr` overwrites the header instead of appending to it (which is what `$proxy_add_x_forwarded_for` does), so a client can't send its own `X-Forwarded-For` and pick which visitor ntfy's rate limiter thinks it is.\n\nI also turned the access log off for this host. Topic names appear in every URL, and on a private server the topic name is part of the secret.\n\n### One Script For Every Sender\n\nEverything on the server that wants to buzz my phone calls one script, `/usr/local/sbin/notify-phone`, with a title as its argument and the body on stdin. It tries my server first and falls back to ntfy.sh over IPv4:\n\n```bash title=\"/usr/local/sbin/notify-phone\"\n#!/bin/bash\nset -uo pipefail\nTITLE=\"${1:-server alert}\"; PRIO=\"${2:-default}\"; TAGS=\"${3:-warning}\"\n. /etc/profile.d/ntfy.sh # NTFY_TOPIC, NTFY_URL (not secret)\n. /etc/notify-phone/publish.env # NTFY_TOKEN (root:alerts 0640)\nBODY=$(head -c 3800) # ntfy messages max out at 4,096 bytes\n\ncode=$(printf '%s' \"$BODY\" | curl -sS --max-time 15 -o /dev/null -w '%{http_code}' \\\n -H @<(printf 'Authorization: Bearer %s\\n' \"$NTFY_TOKEN\") \\\n -H \"Title: $TITLE\" -H \"Priority: $PRIO\" -H \"Tags: $TAGS\" \\\n --data-binary @- \"$NTFY_URL/$NTFY_TOPIC\")\n[ \"$code\" = \"200\" ] && exit 0\n\n# Fallback: ntfy.sh, once, over IPv4 only.\nfcode=$(printf '%s' \"$BODY\" | curl -4 -sS --max-time 15 -o /dev/null -w '%{http_code}' \\\n -H \"Title: $TITLE\" -H \"Priority: $PRIO\" -H \"Tags: $TAGS,fallback\" \\\n --data-binary @- \"https://ntfy.sh/$NTFY_TOPIC\")\n[ \"$fcode\" = \"200\" ] && exit 0\nlogger -t notify-phone \"alert NOT delivered: '$TITLE' (HTTP $code, fallback $fcode)\"\nexit 1\n```\n\n`NTFY_URL` is `http://127.0.0.1:2586`, so the normal path never leaves the machine, doesn't go through nginx and isn't rate limited. The token goes to curl through `-H @<(...)`: curl reads the header from a file descriptor, so the token never shows up in the process list where any user on the box could see it with `ps`.\n\nThe fallback adds a `fallback` tag. My phone stays subscribed to the same topic on ntfy.sh too, so if my server's ntfy is down I still hear about it, and the tag tells me which path it took. The real version of this script also logs each failure and exits early with a clear message if the topic or token is missing.\n\nHaving one script is most of the value. When I changed how alerts are delivered, I changed one file, and every check on the server picked it up.\n\nThe apps running on the server took a little longer. Each one had its own few lines of code that POSTed straight to ntfy.sh, which is exactly the \"anything else on the server\" problem from earlier. They now read two environment variables, the server's URL and the same write-only token, and send an `Authorization: Bearer` header. Nothing on the box talks to ntfy.sh anymore except the fallback and the iOS wake-ups.\n\n### Subscribing From The Phone\n\nIn the ntfy app on iPhone:\n\n1. Settings, then **Users**, then **Add user**. Enter the service URL (`https://ntfy.example.com`), the `phone` username and its password.\n2. Subscriptions, then **+**. Enter the topic name, turn on **Use another server** and enter the same URL.\n\nAndroid works the same way (Settings, then Manage users; then + and \"Use another server\"). The web app at the server's own URL works too, after signing in.\n\niOS needs one more piece on the server. Apps can't keep a connection open in the background there, so a self-hosted server can't wake the phone by itself. That's what `upstream-base-url` is for. When a message arrives, my server sends ntfy.sh a `poll_request` that contains the message ID and the SHA-256 of the topic URL, and nothing else. ntfy.sh passes that through Firebase to Apple's push service, and the phone wakes up and fetches the real message from my server. The [docs on iOS instant notifications](https://docs.ntfy.sh/config/#ios-instant-notifications) walk through it. The alert text never goes to ntfy.sh. If the phone can't reach my server in time, it shows \"New message\".\n\nThose poll requests are requests to ntfy.sh, so they count against the same per-address budget as everything else. I run the ntfy service with `RestrictAddressFamilies=AF_INET AF_UNIX` in a systemd drop-in, which leaves it unable to open an IPv6 socket, so its outbound requests go over IPv4. ntfy also has an `upstream-access-token` setting for the case where the upstream poll still hits a limit: it authenticates those requests to ntfy.sh with an account token instead of counting them against your address.\n\n### Testing It\n\nA test from the server:\n\n```bash\necho \"hello from the server\" | sudo /usr/local/sbin/notify-phone \"ntfy test\" default test_tube\n```\n\n`test_tube` is one of ntfy's emoji tags, so the test shows up with a little test tube on it. To test the fallback, stop the service with `sudo systemctl stop ntfy` and send it again. The message should arrive through ntfy.sh with the `fallback` tag, and `journalctl -t notify-phone` shows which path each alert took.","html_content":"

My server sends push notifications to my phone when something needs a look: memory running low, a process that stopped answering on its port, a nightly job that failed. For a long time those went through ntfy, which is about the nicest way there is to get a message from a shell script onto a phone. You POST some text to a URL and your phone buzzes:

\n
Shell
curl -d \"Backup job failed\" https://ntfy.sh/your-alert-topic

Then one day every alert started coming back 429 Too Many Requests. Nothing on my side had changed, and the same request from my Mac went through fine.

\n

What ntfy.sh Counts

\n

ntfy.sh is free and has no accounts for publishing, so its limits are per visitor, and a visitor is an IP address. The publishing docs list the daily cap: “On ntfy.sh, the daily message limit is 250.”

\n

The detail that matters is how ntfy treats IPv6. From the server config docs:

\n
\n

By default, rate limiting for IPv6 is done using the /64 subnet of the visitor’s IPv6 address. This means that all visitors in the same /64 subnet are treated as one visitor.

\n
\n

That’s a sensible default. Home internet providers routinely hand each customer a /64 or bigger, so counting single IPv6 addresses would let anyone dodge the limit by rotating through their own block. An IPv4 address, on the other hand, counts on its own (visitor-prefix-bits-ipv4 defaults to 32).

\n

Where The /64 Comes From

\n

Cloud providers don’t always work like home providers. DigitalOcean’s IPv6 limits page says a droplet gets “a maximum of 16 addresses (a subnet mask of /124)”. The interface itself is configured with a /64 prefix, but my droplet only owns 16 addresses inside it. The rest of that /64 belongs to other droplets.

\n

So from ntfy.sh’s point of view, my server and every other droplet in that /64 that talks to ntfy.sh are one visitor sharing one 250 message budget. That shared budget was empty, and my alerts were getting turned away with it.

\n

Over IPv4, my server is the only one on its address. When a host has both an IPv6 and an IPv4 address and the server can reach both, curl tries IPv6 first, so every alert had been going out over the shared one.

\n

Checking It Yourself

\n

ntfy.sh will tell you how it sees you. GET /v1/account without credentials describes the anonymous visitor you’re being counted as, including messages sent and remaining today. Ask once over each address family and compare:

\n
Shell
curl -6 -s https://ntfy.sh/v1/account | jq '.limits.basis, .stats'\ncurl -4 -s https://ntfy.sh/v1/account | jq '.limits.basis, .stats'

basis comes back as "ip", and stats.messages_remaining is the number to look at. If the IPv6 line is at zero while you’ve barely sent anything, you’re sharing a /64. The daily counter resets at midnight UTC.

\n

The Quick Fix: curl -4

\n

The fastest fix is one flag. -4 makes curl resolve and connect over IPv4 only:

\n
Shell
curl -4 -d \"Backup job failed\" https://ntfy.sh/your-alert-topic

When I tested it, the same request that got a 429 over IPv6 got a 200 over IPv4. If you use ntfy.sh from a cloud server and want alerts back in five minutes, that’s the change to make.

\n

It only covers the senders you remember to change, though. Anything else on the server that talks to ntfy.sh (a cron job, an app’s own notification code, a library with its own HTTP client) still spends from whichever budget it lands on, and your important alerts share both budgets with all of it. I wanted my alerts to stop depending on a free public quota at all.

\n

Running My Own ntfy

\n

ntfy is a single Go binary with an official apt repository, and it’s the same open-source server that ntfy.sh runs. I installed the package, which comes with a systemd unit and an ntfy user, and kept it on loopback behind nginx. The config that matters, from /etc/ntfy/server.yml:

\n
/etc/ntfy/server.ymlYAML
base-url: \"https://ntfy.example.com\"\nlisten-http: \"127.0.0.1:2586\"\nbehind-proxy: true\n\n# Nothing is readable or writable without a user or token.\nauth-file: \"/var/lib/ntfy/user.db\"\nauth-default-access: \"deny-all\"\nenable-signup: false\nenable-login: true\nrequire-login: true\n\n# Keep messages for 48 hours so the phone can catch up after being offline.\ncache-file: \"/var/cache/ntfy/cache.db\"\ncache-duration: \"48h\"\n\n# iOS instant delivery (more on this below).\nupstream-base-url: \"https://ntfy.sh\"\n\n# Scripts on the server publish over loopback and skip the request limit.\nvisitor-request-limit-exempt-hosts: \"127.0.0.1,::1\"

auth-default-access: "deny-all" is the line that makes it private. Out of the box ntfy lets anyone read and write any topic, which is how ntfy.sh works and why its topic names have to be hard to guess. With deny-all, an unknown topic is closed to everyone until you grant access to it.

\n

behind-proxy: true tells ntfy to take the client’s address from X-Forwarded-For. Without it, every request arrives from nginx’s 127.0.0.1 and every phone and browser gets rate limited as one visitor.

\n

Users And Tokens

\n

I made three users with the ntfy CLI, each with only what it needs:

\n
Shell
sudo -u ntfy ntfy user add --role=admin admin-user\nsudo -u ntfy ntfy user add publisher\nsudo -u ntfy ntfy user add phone\n\nsudo -u ntfy ntfy access publisher your-alert-topic write-only\nsudo -u ntfy ntfy access phone your-alert-topic read-only\n\nsudo -u ntfy ntfy token add --label=server-alerts publisher

The scripts on the server never use a password. They use an access token (tk_...) for the publisher user, which can post to the alert topic and can’t read anything. The phone signs in as phone, which can read the topic and can’t post. If either credential leaks, the damage stops at that one ability on that one topic.

\n

The token lives in a small env file owned by root, with a group for the accounts allowed to send alerts, mode 0640. ntfy user add reads the password from the NTFY_PASSWORD environment variable if it’s set, so it never has to show up in a command line.

\n

The nginx Side

\n

nginx terminates TLS and passes everything to the loopback port:

\n
/etc/nginx/sites-available/ntfy.example.comnginx
server {\n  listen 443 ssl;\n  server_name ntfy.example.com;\n  access_log off;   # topic names are in the URLs\n\n  location / {\n    proxy_pass http://127.0.0.1:2586;\n    proxy_http_version 1.1;\n    proxy_buffering off;                        # streaming subscriptions\n    proxy_set_header Host $http_host;\n    proxy_set_header Upgrade $http_upgrade;     # WebSocket subscriptions\n    proxy_set_header Connection \"upgrade\";\n    proxy_set_header X-Forwarded-For $remote_addr;\n    proxy_set_header X-Forwarded-Proto $scheme;\n    proxy_read_timeout 3m;\n  }\n}

Two lines are easy to get wrong. proxy_buffering off matters because the web app and some clients hold a connection open and stream messages as they arrive, and a buffering proxy sits on them. And X-Forwarded-For $remote_addr overwrites the header instead of appending to it (which is what $proxy_add_x_forwarded_for does), so a client can’t send its own X-Forwarded-For and pick which visitor ntfy’s rate limiter thinks it is.

\n

I also turned the access log off for this host. Topic names appear in every URL, and on a private server the topic name is part of the secret.

\n

One Script For Every Sender

\n

Everything on the server that wants to buzz my phone calls one script, /usr/local/sbin/notify-phone, with a title as its argument and the body on stdin. It tries my server first and falls back to ntfy.sh over IPv4:

\n
/usr/local/sbin/notify-phoneShell
#!/bin/bash\nset -uo pipefail\nTITLE=\"${1:-server alert}\"; PRIO=\"${2:-default}\"; TAGS=\"${3:-warning}\"\n. /etc/profile.d/ntfy.sh                 # NTFY_TOPIC, NTFY_URL (not secret)\n. /etc/notify-phone/publish.env          # NTFY_TOKEN (root:alerts 0640)\nBODY=$(head -c 3800)                     # ntfy messages max out at 4,096 bytes\n\ncode=$(printf '%s' \"$BODY\" | curl -sS --max-time 15 -o /dev/null -w '%{http_code}' \\\n  -H @<(printf 'Authorization: Bearer %s\\n' \"$NTFY_TOKEN\") \\\n  -H \"Title: $TITLE\" -H \"Priority: $PRIO\" -H \"Tags: $TAGS\" \\\n  --data-binary @- \"$NTFY_URL/$NTFY_TOPIC\")\n[ \"$code\" = \"200\" ] && exit 0\n\n# Fallback: ntfy.sh, once, over IPv4 only.\nfcode=$(printf '%s' \"$BODY\" | curl -4 -sS --max-time 15 -o /dev/null -w '%{http_code}' \\\n  -H \"Title: $TITLE\" -H \"Priority: $PRIO\" -H \"Tags: $TAGS,fallback\" \\\n  --data-binary @- \"https://ntfy.sh/$NTFY_TOPIC\")\n[ \"$fcode\" = \"200\" ] && exit 0\nlogger -t notify-phone \"alert NOT delivered: '$TITLE' (HTTP $code, fallback $fcode)\"\nexit 1

NTFY_URL is http://127.0.0.1:2586, so the normal path never leaves the machine, doesn’t go through nginx and isn’t rate limited. The token goes to curl through -H @<(...): curl reads the header from a file descriptor, so the token never shows up in the process list where any user on the box could see it with ps.

\n

The fallback adds a fallback tag. My phone stays subscribed to the same topic on ntfy.sh too, so if my server’s ntfy is down I still hear about it, and the tag tells me which path it took. The real version of this script also logs each failure and exits early with a clear message if the topic or token is missing.

\n

Having one script is most of the value. When I changed how alerts are delivered, I changed one file, and every check on the server picked it up.

\n

The apps running on the server took a little longer. Each one had its own few lines of code that POSTed straight to ntfy.sh, which is exactly the “anything else on the server” problem from earlier. They now read two environment variables, the server’s URL and the same write-only token, and send an Authorization: Bearer header. Nothing on the box talks to ntfy.sh anymore except the fallback and the iOS wake-ups.

\n

Subscribing From The Phone

\n

In the ntfy app on iPhone:

\n
    \n
  1. Settings, then Users, then Add user. Enter the service URL (https://ntfy.example.com), the phone username and its password.
    2. \n
  2. Subscriptions, then +. Enter the topic name, turn on Use another server and enter the same URL.
    3. \n
\n

Android works the same way (Settings, then Manage users; then + and “Use another server”). The web app at the server’s own URL works too, after signing in.

\n

iOS needs one more piece on the server. Apps can’t keep a connection open in the background there, so a self-hosted server can’t wake the phone by itself. That’s what upstream-base-url is for. When a message arrives, my server sends ntfy.sh a poll_request that contains the message ID and the SHA-256 of the topic URL, and nothing else. ntfy.sh passes that through Firebase to Apple’s push service, and the phone wakes up and fetches the real message from my server. The docs on iOS instant notifications walk through it. The alert text never goes to ntfy.sh. If the phone can’t reach my server in time, it shows “New message”.

\n

Those poll requests are requests to ntfy.sh, so they count against the same per-address budget as everything else. I run the ntfy service with RestrictAddressFamilies=AF_INET AF_UNIX in a systemd drop-in, which leaves it unable to open an IPv6 socket, so its outbound requests go over IPv4. ntfy also has an upstream-access-token setting for the case where the upstream poll still hits a limit: it authenticates those requests to ntfy.sh with an account token instead of counting them against your address.

\n

Testing It

\n

A test from the server:

\n
Shell
echo \"hello from the server\" | sudo /usr/local/sbin/notify-phone \"ntfy test\" default test_tube

test_tube is one of ntfy’s emoji tags, so the test shows up with a little test tube on it. To test the fallback, stop the service with sudo systemctl stop ntfy and send it again. The message should arrive through ntfy.sh with the fallback tag, and journalctl -t notify-phone shows which path each alert took.

","created_at":"2026-10-30T13:00:00.000Z","updated_at":"2026-10-30T13:00:00.000Z"}