How to run your own Nostr relay in 2026

Running a Nostr relay is approachable. The software is open source, the protocol is simple, and a usable relay runs on a $5 VPS. If you have self-hosted anything before, you can run a relay in an afternoon.

Whether you should is a different question. Most users do not need their own relay. Some specific cases benefit strongly.

This guide is the end-to-end walkthrough for someone who wants to try.

Install strfry or nostream on a small VPS, point a domain at it, open port 443. Takes about an hour for someone comfortable with Linux. Running costs $5-15/month. Useful for specific communities, privacy-conscious users, and anyone who wants deeper control over their Nostr infrastructure.

When you are ready, grab your @nostr.blog address →

Why you might want to run one

Six legitimate reasons. If none apply, use public relays instead.

Community relay. You want a relay for a specific group (a company's Nostr, a hobby community, a local meetup). Your relay's policies reflect that group's norms. Outside spammers cannot flood it because you control write access.

Privacy. You want at least one relay in your setup where you know the operator. Your reading habits on that relay are not seen by any third party.

Retention. Public relays sometimes prune old events. Your own relay keeps your posts indefinitely if you want.

Experimentation. You are building a client, a relay extension, or testing new NIPs. Having your own relay is essential for development.

Region-specific performance. No good relay exists in your geographic area. Running one in your region serves you (and possibly others) better.

Principle. You value contributing to the network by hosting a node. This is rare but real; some operators run relays because Nostr's health depends on many independent ones.

Choosing relay software

The two major open-source choices as of April 2026:

strfry. Written in C++, uses LMDB for storage, extremely fast. Handles large event loads (millions of events) on modest hardware. The choice for performance-focused relays.

nostream. TypeScript, runs on Node.js, uses PostgreSQL. Easier to hack on if you know JavaScript. Good for custom policies and plugins.

Several other options exist (rnostr in Rust, khatru framework for Go, various forks). For a first relay, strfry or nostream cover the common case; both are well-documented and actively maintained.

This guide uses strfry for the concrete walkthrough.

Hardware requirements

For a small relay (tens to hundreds of users):

• VPS: 1-2 CPU cores, 1-2 GB RAM
• Storage: 10-50 GB depending on retention
• Bandwidth: 100-500 GB/month
• Cost: $5-15/month on Hetzner, DigitalOcean, Linode, or similar

For a medium relay (thousands of users):

• VPS: 4 CPU cores, 4-8 GB RAM
• Storage: 200+ GB, ideally SSD
• Bandwidth: 1+ TB/month
• Cost: $30-80/month

Most first-time relay operators start with a $5 VPS, which is more than enough for a hundred users.

Setup walkthrough: strfry on Ubuntu

Concrete steps for a basic deployment. Assumes a fresh Ubuntu 22.04+ VPS.

Step 1: Prepare the server

# Update the system
sudo apt update && sudo apt upgrade -y

# Install build dependencies
sudo apt install -y git build-essential libssl-dev libz-dev \
    liblmdb-dev libflatbuffers-dev libsecp256k1-dev \
    libzstd-dev pkg-config

Step 2: Clone and build strfry

cd /opt
sudo git clone https://github.com/hoytech/strfry.git
cd strfry
sudo git submodule update --init
sudo make setup-golpe
sudo make -j4

Build takes about 5-10 minutes on a small VPS.

Step 3: Configure the relay

Edit /opt/strfry/strfry.conf. The important sections:

• db path: where events are stored
• network bind address and port
• info section: relay name, description, contact, public keys
• retention policies: how long to keep events

For a basic setup, the defaults work. Customize the info section to describe your relay.

Step 4: Set up the service

Create a systemd unit so strfry runs persistently. /etc/systemd/system/strfry.service:

[Unit]
Description=strfry Nostr relay
After=network.target

[Service]
ExecStart=/opt/strfry/strfry relay
WorkingDirectory=/opt/strfry
User=strfry
Restart=always

[Install]
WantedBy=multi-user.target

Create the user and enable:

sudo useradd -r -s /bin/false strfry
sudo chown -R strfry:strfry /opt/strfry
sudo systemctl enable --now strfry

Step 5: Set up TLS (reverse proxy)

Nostr clients expect wss:// (WebSocket over TLS). Use Caddy or Nginx in front of strfry.

Caddy is easiest. Install:

sudo apt install -y caddy

Configure /etc/caddy/Caddyfile:

your-relay-domain.com {
    reverse_proxy /* localhost:7777
}

Reload: sudo systemctl reload caddy. Caddy automatically gets a TLS certificate from Let's Encrypt.

Step 6: Point DNS

Create an A record for your-relay-domain.com pointing at your VPS's IP. Wait a few minutes for DNS to propagate.

Step 7: Verify

From your laptop:

curl -s https://your-relay-domain.com

Should return a short response confirming the relay is up. In a Nostr client, add wss://your-relay-domain.com to your relay list. You should see it as connected and start receiving events.

Total elapsed time: 30-60 minutes for someone familiar with Linux; 2-3 hours for a first-timer.

Operating the relay

Once running, a relay requires minimal maintenance. A few recurring tasks:

Monitor disk usage. strfry's database grows with retained events. Check monthly; prune if needed.

Update the software. strfry gets updates; you rebuild when there are meaningful ones. Usually a few times per year.

Check logs for spam patterns. A relay under heavy spam attack may need rate-limit adjustments or policy tightening.

Renew TLS. Caddy does this automatically. If you use Nginx manually, set up certbot auto-renewal.

Back up the database. For small relays, a weekly rsync to another server is fine. For data you care about strongly, more frequent.

Total time commitment: maybe 30 minutes a month once the relay is stable.

Policies to decide

Your relay's rules are yours. Decide early and document them.

Who can write. Fully open (any signed event)? Whitelist (specific pubkeys)? Paid (sat fee per event)?

What kinds. Accept all event kinds, or only specific ones (kind:1 only, no reposts, no reactions)?

Rate limiting. How many events per minute per pubkey? Default strfry limits are reasonable; tighten if abused.

Retention. Keep events forever, or prune after X days? Pruning reduces disk but loses history.

Moderation. Do you manually remove specific events or specific pubkeys? You are the admin; you can.

Publish your policies at / (the info response) so users know what to expect. An opaque relay is a red flag to users.

Costs in practice

A realistic annual budget for a small public relay:

• VPS: $60-180
• Domain: $12-15
• Monitoring and backup tools (optional): $0-60
• Your time: 5-10 hours over the year
• Total cash: $80-250/year

For a paid relay with subscribers, the revenue can cover this and more. For a free relay, it is an out-of-pocket contribution to the network (or to your own use).

Running at scale

Small relays are easy. Growing into the hundreds-of-thousands-of-users range requires real operations work.

Considerations:

• Database optimization. Default strfry/nostream settings work up to a point. Beyond ~500k active users, custom indexing and tuning matters.
• Geographic distribution. A relay in one region cannot serve the world at low latency. Big relays often run clusters.
• DDOS protection. Popular relays get attacked. Cloudflare in front of the relay, or other DDOS services, is common.
• Cost at scale. A relay serving millions of reads per day can cost thousands of dollars per month in bandwidth and compute.

Very few operators run at this scale. Damus-relay, nos.lol, relay.primal.net, and a handful of others are the current heavyweights. Small relays do not need to compete; the network benefits from both.

Why you might not want to run one

Honest reasons to stay as a user of public relays.

• You have no specific reason. Running for principle is fine; running for principle without any other motivation wears off.
• You do not enjoy sysadmin work. The relay is not complex, but you will touch Linux configurations, logs, and TLS occasionally.
• You already trust the public relays. If the defaults work for you, adding your own is extra work without clear gain.
• You do not publish or read enough to justify it. Casual users rarely need their own relay.

There is no pressure in the Nostr community to run your own relay. Most active users do not. The network does not need every user to contribute infrastructure; it needs enough to stay decentralized.

After it is running

Tell people. A relay with no users is not a relay; it is a backup. Post on Nostr about your new relay, explain its policies, and invite users who fit the policies to connect. Expect 10-50 users in the first month if you promote it; more if you are known in a specific community.

Running a relay contributes to the health of the network and gives you a piece of infrastructure that is genuinely yours. For the right user, it is a rewarding project.