Palace Server

Run your own visual chat server—your rooms, your scripts, your community.

You control the experience: hosting at home or in the cloud, with props, Palace scripts, and house rules that match how you want people to hang out.

Download pserver Command reference Linux admin guide

Production checklist, script downloads, systemd & nginx — for Debian/Ubuntu VPS operators.

Why upgrade?

The Palace Server 4.5.1 build shipped Thu Jul 27 2000. That was twenty-six years ago. i686 support in the Linux kernel is winding down and libraries and security updates are not being supported in that legacy runtime. Today’s server is built for current operating systems and modern architecture, while the protocol and room behavior is compatible with familiar Palace clients, and adds moderation tools that reflect the 2020's.

Features for everyone

Visitors and regulars benefit even when they never touch a config file.

  • Same Palace you remember. Drop in with familiar clients; the wire protocol and room experience are built to match the classic server so people are not stranded on old software.
  • Clear server identity. Welcome text can show owner, description, website link, capacity, and visitor activity (today / this week) so newcomers see what kind of place they joined.
  • Optional message-of-the-day. Operators can set or clear a short banner that appears when you arrive.
  • Better privacy controls (where enabled). Personal settings for ignoring cross-room messages and private messages can be saved so they stick when you return.
  • Ratbot. Built-in bot support—operators can run greeters, trivia, and other room bots without everyone needing a special client or extra wiring.
  • Nick registration. Hosts can run servers where names are tied to registered accounts, so identity is clearer than ad-hoc guest handles alone.
  • Full Unicode in nametags and chat (with capable clients). Emojis and international glyphs show up end-to-end when the client supports them—try our Palace client. Older clients may still connect but show placeholders or limited characters.

For hosts and operators

Reasons people who actually run the machine care about the new stack.

  • Drop-in binaries. One file per platform (Windows, Intel and Apple Mac, Linux on common CPUs); no compiler or SDK required to run. Checksums are published for downloads.
  • Cross-platform hosting. The same program runs on a home PC, a VPS, or small ARM boards.
  • Simpler media uploads. Wizards can use their wiz pass to upload backgrounds directly, or gods can restrict it to themselves. Either way, you don't need FTP these days!
  • Behind HTTPS and CDNs. Put a public https:// front on media and have the server tell clients the right public URL—good for TLS and caching.
  • Stronger operator credentials. Wizard and god (and optional owner/host) passwords are stored as modern password hashes instead of reversible legacy encoding; promotion passwords can be rotated or disabled from inside the client.
  • Extra owner tier (optional). A "owner" level above god for the smallest circle of trust—only exists when you turn it on.
  • Host pass (optional). A “host” password tech support can use to get on any palace, and this is encrypted with bcrypt so it's not reversable by the most dedicated bad guys.
  • Delegated operators. Patterns for named operator accounts and controlled promotion, so not everyone shares one global god password.
  • Richer moderation. IP, account, and identity-based rules; timed removes; tracking without always kicking; operator commands aimed at fast response; moderation data kept in structured files beside the mansion script for backup and tooling.
  • Optional chat audit. Structured logs (formats like JSON or CSV) for compliance or incident review, with configurable scope—room chat, whispers, cross-room messages.
  • Safer partial updates. Configuration and mansion changes flush to disk promptly so a crash loses less work than waiting for a slow save cycle like the old server.
  • Roombot. Wizard commands turn on a per-room bot where you want it—set its name, room chat lines, arrival greetings, and optional extras like weather or dice-and-cards; active rooms can persist across restarts.
  • Production operations. Example service definitions and scripts for systemd (Linux), launchd (macOS), and Task Scheduler (Windows) fit “install as a service” expectations on each OS.