How to Install Buzz on a VPS for Your Team

Your team needs a shared place for conversations, files and work with AI agents. You also want control over the server that runs it. Self-hosting Buzz on a VPS gives you that infrastructure control, provided you are ready to manage updates, access and backups.

This guide explains how to install Buzz by Block using its Docker Compose deployment bundle, connect a domain, enable HTTPS and add team members. It is written for a fresh Ubuntu VPS with administrator access. Buzz is still evolving, so begin with a small pilot and check the current project documentation before using it for critical work.

What is Buzz and who is it for

Buzz is an open-source workspace for people and AI agents. Its architecture uses Nostr identities and a relay server, with supporting services for database storage, caching and uploaded objects. This article covers Block’s Buzz workspace, rather than similarly named audio transcription tools.

Self-hosting can suit a development team that wants to choose its infrastructure and manage membership. It also creates ongoing responsibilities: someone must monitor disk space, protect credentials, apply updates and prove that backups can be restored.

Running your own server does not automatically make every conversation end-to-end encrypted or satisfy a particular compliance requirement. Review the project’s current security model against your team’s needs before moving sensitive information into it.

Choose a VPS that fits your pilot

A small pilot and an organisation-wide workspace have different requirements. Start with a Linux server that supports Docker, has persistent storage and gives you administrative access. DigitalBerg’s VPS hosting is a relevant place to compare available Linux configurations.

As a planning starting point, consider 2–4 vCPUs, 4–8 GB RAM and enough SSD space for the operating system, container images, database and expected uploads. These are sizing suggestions, not official Buzz minimum requirements or a guarantee of capacity. Watch real usage and adjust before inviting a larger team.

If you are comparing virtual infrastructure options, review DigitalBerg’s OpenStack KVM cloud VPS page and confirm the operating system, storage and Docker support for your selected plan. For a workload that eventually needs a whole physical machine, dedicated server hosting is another option. More hardware does not remove the need for a backup and maintenance plan.

What you need before starting

• A fresh Ubuntu 24.04 LTS VPS and a user with sudo privileges.
• A domain or subdomain, such as buzz.example.com, with access to its DNS records.
• Docker Engine and Docker Compose version 2.24.4 or newer.
• A Buzz-compatible client and the workspace owner’s public key in 64-character hexadecimal format.
• A secure place to keep credentials and an off-server backup destination.

The commands below use example domains and paths. Replace the examples with your own values. They follow the upstream deployment files reviewed on 14 October 2026; this is a source-checked guide, not a claim that a live DigitalBerg installation was tested.

Step 1 Connect to the VPS and prepare DNS

Log in using your server’s actual username and IP address:

ssh youruser@YOUR_SERVER_IP

 

If this is your first server, follow DigitalBerg’s guide to connecting to a VPS using SSH before continuing. Keep a working SSH session open while making firewall changes.

Create an A record for your chosen subdomain pointing to the VPS IPv4 address. Add an AAAA record only when the server has working IPv6 configured. A stale IPv6 record can send some visitors and certificate checks to the wrong destination.

Allow incoming HTTP and HTTPS traffic on ports 80 and 443. Restrict SSH access where practical. Do not expose database, Redis or object-storage ports to the public internet. Docker-published ports can bypass some UFW rules, so check both your provider firewall and Docker configuration.

Step 2 Install Docker and check Compose

If Docker is already installed, check its version and Compose before changing anything:

sudo docker version

sudo docker compose version

 

For a new Ubuntu server, follow the repository installation method in the official Docker Engine installation guide. Install the Docker Compose plugin alongside Docker Engine. Using the official instructions avoids hard-coding repository details that may change between Ubuntu releases.

Then confirm that Docker can run a container and install the small tools used below:

sudo docker run –rm hello-world

sudo apt update

sudo apt install -y git openssl nano

 

Compose must be version 2.24.4 or newer because Buzz’s HTTPS override uses the !reset feature. An error mentioning an unknown !reset tag usually means the installed Compose version is too old.

Step 3 Download the Buzz deployment files

Clone the official repository into your home directory and open the production deployment folder:

git clone https://github.com/block/buzz.git “$HOME/buzz”

cd “$HOME/buzz/deploy/compose”

git rev-parse HEAD

cp .env.example .env

chmod 600 .env

 

Record the commit printed by git alongside your deployment notes. It helps you identify the configuration you used if troubleshooting becomes necessary.

Use deploy/compose for this guide. The repository’s root Compose file is intended for local development and is not interchangeable with the VPS deployment bundle.

The current bundle includes the Buzz relay, PostgreSQL, Redis and S3-compatible object storage. Object storage uses Silo, a maintained MinIO fork, while retaining the service name minio. Follow the bundled versions rather than substituting an old MinIO image from an unrelated tutorial.

Step 4 Configure the domain and credentials

Open the environment file:

nano .env

 

Update the following domain settings using your real hostname:

BUZZ_DOMAIN=buzz.example.com

RELAY_URL=wss://buzz.example.com

BUZZ_MEDIA_BASE_URL=https://buzz.example.com/media

BUZZ_MEDIA_SERVER_DOMAIN=buzz.example.com

BUZZ_CORS_ORIGINS=https://buzz.example.com

 

HTTPS protects the web connection, while wss is the secure WebSocket scheme used for the relay connection. The names should match the hostname you configured in DNS.

Set the owner and generate separate secrets

Replace RELAY_OWNER_PUBKEY with the owner’s 64-character hexadecimal public key. If your client shows an npub value, use a trusted Nostr public-key decoding tool to obtain its hex representation. A public key identifies the owner; the private key grants control. Never paste an nsec private key into a public conversion website.

Generate a new random value for each secret by running this command separately each time:

openssl rand -hex 32

 

Use different generated values for BUZZ_RELAY_PRIVATE_KEY, BUZZ_GIT_HOOK_HMAC_SECRET, POSTGRES_PASSWORD, REDIS_PASSWORD, BUZZ_S3_ACCESS_KEY and BUZZ_S3_SECRET_KEY. Keep the existing variable names and replace their placeholder values. The relay private key and the human owner’s private key are different credentials.

Keep these secrets stable across restarts. Changing a password in .env after a database has already been initialised does not necessarily change the password inside that existing database.

For this closed team workspace, retain these settings:

BUZZ_REQUIRE_AUTH_TOKEN=true

BUZZ_REQUIRE_RELAY_MEMBERSHIP=true

BUZZ_AUTO_MIGRATE=true

 

Automatic migration requires an image containing the project’s embedded migrations. Keep optional admin interfaces and push notifications disabled unless you have reviewed and configured them deliberately.

Choose the image deliberately

The example configuration currently points BUZZ_IMAGE at ghcr.io/block/buzz:main. That moving tag is useful for early testing. For an ongoing deployment, select an available, tested release tag or image digest and record it. Check compatibility between the selected image and deployment files; do not assume the newest main image is a stable production release.

Before starting, check for unresolved placeholders without printing your secret values:

if grep -q ‘CHANGE_ME’ .env; then

echo “Replace the remaining placeholders before starting.”

else

echo “No CHANGE_ME placeholders found.”

fi

 

This catches unchanged placeholders; it does not prove every setting is correct.

Step 5 Start Buzz with HTTPS enabled

Use the Caddy override from the first start. It publishes ports 80 and 443 and removes the relay’s direct public port mapping.

To keep the commands readable, define this helper in your current shell while you are inside deploy/compose:

dc() {

sudo docker compose –env-file .env \

-f compose.yml -f compose.caddy.yml “$@”

}

dc config –quiet

dc pull

dc up -d –wait

dc ps -a

 

Run the commands in order and resolve any error before continuing. The dc helper applies only to your current shell; after reconnecting, return to this folder and define it again.

Caddy needs your hostname to resolve to this VPS and the required public ports to be reachable before it can obtain a certificate. Check the logs if startup or certificate issuance fails:

dc logs –tail=100 caddy relay

 

The minio-init service is a one-time bucket setup job, so an exit code of zero is expected. Repeated restarts or an unhealthy state in a long-running service need investigation. Avoid posting complete logs publicly without checking them for private information.

Step 6 Connect the client and invite a test member

Obtain a compatible client through the official Buzz project. Sign in with the owner identity you configured and connect to your relay at wss://buzz.example.com, replacing the example hostname.

Add a team member using their public key:

dc exec relay /usr/local/bin/buzz-admin add-member \

–pubkey MEMBER_NPUB_OR_HEX –role member

dc exec relay /usr/local/bin/buzz-admin list-members

 

Replace MEMBER_NPUB_OR_HEX before running the command. Add members sequentially; the current helper notes recommend at least one second between additions to avoid roster-event timestamp collisions. Grant administrator access only when needed.

Test with two accounts before inviting the whole team. Send a message, reconnect, upload a small non-sensitive file and confirm another authorised member can retrieve it. Also confirm that an unapproved identity cannot join your closed workspace. A running container alone is not a complete application test.

Step 7 Make a backup you can restore

Messages and uploads do not necessarily live in the same storage layer. A database-only backup can leave you with message records that point to missing files.

Your recovery plan should cover PostgreSQL, object storage, the git data volume, configuration and secrets, and Caddy’s persistent state. Protect the owner identity’s recovery material separately. Include Redis persistence if your recovery procedure requires preserving its state.

Use a coordinated maintenance window or an application-consistent backup procedure so the database and uploaded objects represent the same point in time. Copy encrypted backups away from the VPS. A second folder on the same disk will not help if that disk is lost.

Restore into an isolated environment and verify login, membership, messages and file downloads. Do this before relying on the workspace. Avoid docker compose down -v during routine maintenance because it removes named volumes and can destroy persistent data.

Common Buzz installation problems

The certificate is not being issued

Check the A record, any AAAA record, ports 80 and 443, and whether another web server already occupies those ports. Read the Caddy logs for the specific failure rather than repeatedly restarting the whole stack.

The relay starts but users cannot connect

Confirm that the client uses wss with the correct hostname. Check the owner key format, member list, authentication settings and relay logs. A public HTTPS response by itself does not prove that an authenticated WebSocket connection works.

Uploads fail while messages work

Check the minio-init result, object-storage service health, available disk space and media-domain settings. Preserve the bundled internal S3 endpoint and path-style addressing unless you are deliberately implementing a different supported storage configuration.

The server becomes slow

Inspect CPU, memory, disk capacity and container logs before buying a bigger plan. Large uploads, storage pressure and repeated application failures can cause different symptoms. Measure the bottleneck, then decide whether to increase VPS resources or change the deployment.

Keep the workspace maintained

Assign an owner for updates, backups and membership reviews. Monitor disk usage and service health, and test recovery on a schedule that fits how much data your team can afford to lose.

Before upgrading, read the upstream changes, back up the existing installation and test the new image with compatible configuration. Database migrations may make a simple image rollback unsafe. Keep a documented recovery route rather than assuming you can always switch the tag back.

If you are also exploring local AI infrastructure, read DigitalBerg’s OpenClaw with Ollama VPS guide. It covers a separate setup; installing Buzz does not automatically install Ollama or connect an AI model.

Frequently asked questions

Can I install Buzz on shared web hosting

This deployment needs Docker, persistent services and administrator control. A conventional shared hosting account usually does not provide that environment. Check the actual hosting capabilities before ordering.

Do I need a GPU to host Buzz

The Compose stack in this guide does not require a GPU service. Running a separate local AI model is a different workload with its own memory and hardware requirements.

Is a domain required

A domain or subdomain is the practical choice for this public deployment because the guide uses Caddy to obtain certificates for a hostname. Local experiments can use a different setup, but that is outside this HTTPS workflow.

Is Buzz ready for a business critical workspace

The upstream project is evolving. Evaluate the current release, client support, security model and recovery process in a pilot before making it essential to daily operations.

Does buying a VPS include Buzz management

Do not assume it does. Confirm who is responsible for application installation, updates, backups and incident response before selecting a hosting plan or support arrangement.

Build a pilot your team can trust

Start with a small group, verify access and file sharing, and complete a restore test. That gives you evidence that the workspace is usable and recoverable before you expand it.

Explore DigitalBerg’s VPS, cloud VPS and dedicated server options linked above, then confirm a configuration that suits your pilot. Choose the server with your storage and maintenance needs in mind, and grow from measured usage.