Build and run your own multiplayer text world.

SharpMUSH is an open-source MUSH server for collaborative stories, roleplay and world building. A game plays out in a MU* client, a browser and a Discord server at once, and its systems are written in softcode that builders and players can read and change.

Try the live example · Run a game · Read the docs

• Build together. Create rooms, characters and shared stories with familiar MUSH softcode.
• Play from anywhere. Connect with a MU* client or the web portal, which has a Play terminal, mail, scenes and the wiki, and works on a phone and with screen readers. MUD clients such as Mudlet get a map and gauges over GMCP.
• Bridge Discord. Link Discord channels to the game, so lines go both ways under each member's chosen character. Players can sign in with Discord, Google and others.
• Run roleplay and staff work. Scenes log roleplay as it happens, the wiki holds pages with facts the portal and softcode can search, and jobs track what players ask staff for.
• Softcode first. Game systems ship as softcode packages you install, upgrade and remove, and portal pages can be softcode too. C# plugins add to the engine without a fork.
• Let other tools in. Apps act as a character with only the rights its player allowed, and editors check softcode through the language server.
• Bring an existing world. Import a PennMUSH, RhostMUSH or TinyMUX database with its mail. SharpMUSH runs PennMUSH softcode, with the differences listed, and understands much of TinyMUX and RhostMUSH softcode too.

Ask questions on Discord · Explore the package library · Develop SharpMUSH

The first release, 1.0.0, is being prepared. See CHANGELOG.md for what each release contains.

To launch a game on a host, see Launch a Server, or deploy one on Railway:

SharpMUSH is available as Docker images on DockerHub:

• sharpmush/sharpmush-server - Main server
• sharpmush/sharpmush-socketserver - Stable telnet/WebSocket socket owner
• sharpmush/sharpmush-renderer - Replaceable rendering worker
• sharpmush/sharpmush-edge - Caddy, NATS and the socket server in one image, run beside the server and renderer images on hosts that run one container per app (Fly.io, Railway)
• sharpmush/sharpmush-allinone - Everything in one image, for a one-app game on those hosts

For information on setting up automatic DockerHub publishing when new versions are released, see DockerHub Setup Guide.

The full guide to running SharpMUSH from source and running its tests is Develop SharpMUSH on the documentation site.

• Install .NET 11 — SDK 11.0.100 or newer, as pinned in global.json
• Install Docker Desktop

Build with:

dotnet build

Run the tests with:

dotnet test

Note: Test telemetry output is disabled by default to reduce console noise. To enable telemetry metrics during test runs, set the environment variable:

export SHARPMUSH_ENABLE_TEST_TELEMETRY=true
dotnet test

The main entrypoint to set as a Startup Project is SharpMUSH.Server.

For full integration, run SharpMUSH.SocketServer, which owns client sockets, and SharpMUSH.RenderingWorker, which renders output over a shared Unix socket. To run all three in Docker, with NATS, use the Compose files in deploy/. They build the images from your checkout:

cd deploy
cp .env.example .env    # set SHARPMUSH_DOMAIN (localhost on your own machine)
docker compose -f docker-compose.prod.yml up -d --build

When launching projects separately on Linux, set Rendering__SocketPath to the same writable path (for example /tmp/sharpmush-render.sock) for both SocketServer and RenderingWorker, and provide NATS_URL to SocketServer and the main server. To start NATS on its own, on this computer only:

docker run -d --name sharpmush-dev-nats -p 127.0.0.1:4222:4222 -v "$PWD/nats.conf:/etc/nats/nats.conf:ro" nats:2-alpine -js -c /etc/nats/nats.conf
export NATS_URL=nats://localhost:4222

For quick images from Release binaries, use Dockerfile.socketserver.local for SocketServer and Dockerfile.renderingworker.local for the renderer; mount their shared socket directory.

See connection updates and recovery for migration and restart behavior. The development Kubernetes manifest keeps SocketServer and renderer in one Pod: updating either image replaces that Pod and drops sockets. Use the single-host Compose deployment for independent renderer updates that retain client sockets.

Additionally, a Blazor web client is available at SharpMUSH.Client.