• Why Run a Relay Locally?
• Docker Makes It Portable
• Pubkey Whitelisting
• Not Yet a Permanent Relay
• A Foundation for Local-First Infrastructure
• Work With Me
  • Early Adopters

Andrew G. Stanton - Sunday, March 8, 2026

Today I reached an important milestone while working on Continuum.

I successfully ran a Nostr relay locally inside Docker, with pubkey whitelisting enabled.

Right now the relay exists only on my machine. It is not yet a permanent public relay and it is not exposed to the internet.

But that is actually fine — because even as a local relay it provides a number of important capabilities.

§Why Run a Relay Locally?

Public Nostr relays are incredibly useful, but they are also unpredictable.

Sometimes they:

• drop events
• reject writes
• go offline
• respond slowly

Running a relay locally removes those variables.

When the relay runs on your own machine you gain:

• deterministic behavior
• full visibility into events
• a reliable write target for development

For building software, this is extremely valuable.

§Docker Makes It Portable

The relay runs inside a Docker container.

That means it can be:

• started easily
• reproduced on another machine
• deployed later to a more permanent host

Docker also keeps the environment isolated and predictable.

This is exactly the type of setup that can eventually move from a laptop to a small always-on server with minimal changes.

§Pubkey Whitelisting

One feature I enabled immediately was pubkey whitelisting.

The relay accepts writes only from approved public keys.

This means:

• no spam
• controlled publishing
• predictable event flow

For a personal relay this is a very practical configuration.

§Not Yet a Permanent Relay

Because the relay currently runs on my development machine, events written to it exist only locally.

They are not automatically replicated to the wider Nostr network unless they are also published to external relays.

In other words, this relay currently functions more like a local development relay rather than a permanent public one.

That distinction matters.

But it does not reduce the usefulness of the setup.

§A Foundation for Local-First Infrastructure

Even as a local relay, this configuration opens up new possibilities for Continuum.

It allows the system to:

• publish events to a relay under my control
• debug relay behavior easily
• test publishing logic without external dependencies

Later, the same Docker configuration could run on an always-on machine and become a fully reachable relay endpoint.

For now, though, it serves a different purpose.

It helps build reliable local infrastructure first — and that is exactly where good systems begin.

§Work With Me

If you’re exploring:

• Nostr authentication
• Sovereign identity infrastructure
• AI-assisted workflows
• Local-first containerized systems

I offer a limited number of advisory and implementation sessions for builders, teams, and ministries working in these areas.

Typical engagements include:

• Architecture session (90 minutes) – $500
• Implementation sprint – starting at $2,500
• Ministry / Foundation advisory engagement – $2,500

§Early Adopters

I’m also looking for early adopters interested in running Continuum, a local-first publishing and identity system built on Nostr.

There is no cost for early adopters, and I’m happy to personally help with installation and setup.

Even if you’re just curious and want to see how it works, feel free to reach out.

Feedback from early adopters directly influences the direction of the project.

Contact: andrewgstanton@gmail.com
or DM on Nostr:

@9wvc…guvd

You can also support this work as a Continuum Patron ($250).