Why Self-Host?#

ntfy has an official public server, ntfy.sh, which you can use without installing anything.

But I still chose to self-host, because:

• Topics on the public server are public. Anyone who knows your topic name can send messages to it.
• Self-hosting allows for user authentication.
• Self-hosting allows control over retention and logs.
• My student server has space anyway, and ntfy is very lightweight.

If you’re just trying it out temporarily, using the public ntfy.sh is perfectly fine. But for long-term use, self-hosting is more reliable.

Deployment#

Prepare the directory:

1
sudo mkdir -p /srv/stacks/ntfy
2
sudo chown -R $USER:$USER /srv/stacks/ntfy
3
cd /srv/stacks/ntfy

Write docker-compose.yml:

1
services:
2
  ntfy:
3
    image: binwiederhier/ntfy
4
    container_name: ntfy
5
    restart: unless-stopped
6
    command: serve
7
    environment:
8
      TZ: Asia/Shanghai
9
      NTFY_BASE_URL: "https://ntfy.example.com"
10
      NTFY_AUTH_DEFAULT_ACCESS: "deny-all"
11
    volumes:
12
      - ./cache:/var/cache/ntfy
13
      - ./data:/var/lib/ntfy
14
      - ./etc:/etc/ntfy
15
    ports:
16
      - "127.0.0.1:8090:80"

A few key points:

• Port 127.0.0.1:8090:80: Only listens on localhost. Do not expose directly to the public internet.
• NTFY_AUTH_DEFAULT_ACCESS: "deny-all": Denies all unauthenticated requests by default. This means only you (with a token or username/password) can send and receive.
• NTFY_BASE_URL: Fill in the domain you’ll eventually use, for example, I use ntfy.sayori.org.

Start#

1
docker compose up -d
2
docker compose logs -f

Local check:

1
curl http://127.0.0.1:8090/

You should see ntfy’s Web interface responding.

Create User#

Since we set deny-all, we need to create a user for ourselves:

1
docker compose exec ntfy ntfy user add --role=admin your_username

It will ask you to enter a password. Remember this username and password; you’ll need it later for sending notifications and the mobile app.

You can also generate a token:

1
docker compose exec ntfy ntfy token add your_username

Tokens are more convenient than passwords; you can just include them in the header in scripts.

Connect Domain#

Similar to Vaultwarden, use Cloudflare Tunnel or Caddy/Nginx reverse proxy.

Cloudflare Tunnel route:

1
ntfy.example.com
2
  -> Cloudflare Tunnel
3
  -> 127.0.0.1:8090
4
  -> ntfy

After confirming HTTPS access is working, open https://ntfy.example.com and log in to the Web interface with the account you just created.

Send Your First Notification#

The simplest way:

1
curl -H "Authorization: Bearer your_token" \
2
     -d "Server is still alive" \
3
     https://ntfy.example.com/test

Here, /test is the topic name. You can name it anything you like, such as /backup, /alert, /server.

You can also include a title and priority:

1
curl -H "Authorization: Bearer your_token" \
2
     -H "Title: Backup Complete" \
3
     -H "Priority: default" \
4
     -d "Vaultwarden backup successful, size 2.3MB" \
5
     https://ntfy.example.com/backup

Mobile App#

Android:

• ntfy client is available on F-Droid.
• Also on Google Play.

iOS:

• Search for ntfy in the App Store.

After opening the App:

1. In settings, add your self-hosted server address.
2. Enter your username and password or token.
3. Subscribe to your topics (e.g., backup, alert).

From now on, notifications sent from your server will be pushed to your phone.

Use in Scripts#

Add a line at the end of your backup script:

1
NTFY_URL="https://ntfy.example.com/backup"
2
NTFY_TOKEN="your_token"
3

4
# On successful backup
5
curl -s -H "Authorization: Bearer $NTFY_TOKEN" \
6
     -H "Title: ✅ Backup Successful" \
7
     -d "Vaultwarden backup completed $(date +%F)" \
8
     "$NTFY_URL"
9

10
# On failed backup
11
curl -s -H "Authorization: Bearer $NTFY_TOKEN" \
12
     -H "Title: ❌ Backup Failed" \
13
     -H "Priority: high" \
14
     -d "Vaultwarden backup error, please check logs" \
15
     "$NTFY_URL"

Scheduled task failure notification:

1
some_command || curl -s -H "Authorization: Bearer $NTFY_TOKEN" \
2
     -H "Title: Scheduled Task Failed" \
3
     -H "Priority: high" \
4
     -d "$(hostname): some_command failed to execute" \
5
     "$NTFY_URL"

Integrating with Gatus#

If you’re running Gatus for health checks, you can add ntfy as an alert channel in your Gatus configuration.

Gatus supports native ntfy alerts; just configure the server address, topic, and token.

This way, if a service goes down, Gatus will automatically send a notification to ntfy, and your phone will ring.

Resource Usage#

ntfy is very lightweight.

It’s running on my server, usually consuming about 20-30MB of RAM. CPU usage is practically zero. For a 2C2G server, it’s no burden at all.

It doesn’t require a database. Messages are cached in local files and automatically expire after a certain period.

Important Notes#

• Do not write your ntfy token into public repositories.
• If you set deny-all but some external services (e.g., Gatus sending from the same machine) need to send notifications without authentication, you can open permissions for specific topics.
• Messages are not permanently retained. If you need historical records, the sender should log them itself.
• ntfy’s Web interface does not need to be exposed to the public internet. The mobile app subscribes using the API.

Is it suitable for a 2C2G server?#

Absolutely. It might be one of the most cost-effective services for a 2C2G server.

Once installed, you’ll find that almost every script’s final step becomes “send me a notification with the result.” This is much more comfortable than SSHing in to check logs every day.