Deploy and Host Supermemory on Railway

Supermemory is a memory and context engine for AI. It automatically extracts facts from conversations, builds user profiles, resolves contradictions, and auto-forgets stale information, then serves it back through hybrid RAG + memory search. This template runs the official self-hosted supermemory-server binary — one process, no external database, the full Memory API.

About Hosting Supermemory

Supermemory doesn't publish a Docker image for self-hosting — it ships as a single statically-linked binary from GitHub Releases, installed by a shell script on your own machine. This template reproduces that install step inside a plain debian:bookworm-slim container: on first boot it downloads the pinned supermemory-server release, verifies its sha256 checksum, and runs it, caching the binary on the attached volume so every later restart or redeploy skips the download entirely. There's no separate database — the binary embeds its own encrypted graph engine and writes everything to that same volume, so your data, API key, and cached model survive redeploys.

Common Use Cases

• Personal or team "second brain": persistent memory across every AI conversation, with automatic fact extraction and contradiction handling
• Memory/RAG backend for your own agents and apps — add documents, get hybrid search and auto-maintained user profiles through one API
• Fully private, self-hosted alternative to the hosted Supermemory platform, using your own LLM keys and your own data

Dependencies for Supermemory Hosting

• An LLM provider API key — OPENAI_API_KEY (recommended default) or one of ANTHROPIC_API_KEY / GEMINI_API_KEY / GROQ_API_KEY. Required: the server won't boot at all without one, since there's no terminal on Railway for the interactive setup wizard it normally falls back to.
• Nothing else — vector embeddings run locally by default (Xenova/bge-base-en-v1.5, CPU, no API key needed) and all state lives on the attached volume.

Deployment Dependencies

• Supermemory GitHub repository
• Self-hosting documentation
• supermemory-server releases — the binaries this template downloads

Implementation Details

No Dockerfile, no published image — downloaded at boot instead. Supermemory's self-hosting story is a single binary fetched via an install script (curl -fsSL https://supermemory.ai/install | bash), not a container image. To run it on Railway without maintaining a fork or a separate image registry, the start command does what that install script does — resolve the platform, download the pinned release, verify its sha256 against the published manifest, chmod +x, and exec it — except it caches the binary under /data/bin on the Railway volume instead of re-downloading on every boot:

sh -c 'set -e
VERSION="${SUPERMEMORY_SERVER_VERSION:-0.0.5}"
BIN="/data/bin/supermemory-server-$VERSION"
if [ ! -x "$BIN" ]; then
  # download + sha256-verify supermemory-server-$PLATFORM from
  # github.com/supermemoryai/supermemory/releases/download/server-v$VERSION/
  ...
fi
exec "$BIN"'

Bump SUPERMEMORY_SERVER_VERSION to upgrade — the new binary downloads alongside the old one on the next deploy.

Healthcheck. GET / returns the app shell with HTTP 200 without authentication, so it's used directly as the healthcheck path. Timeout is set to 600s to comfortably cover a first-boot binary download plus the local embedding model's first-run download.

Why Deploy Supermemory on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Supermemory on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.