Deploy and Host AutoVault on Railway

What is AutoVault?

AutoVault is a curated capability library for AI agents. It stores, validates, signs, and serves SKILL.md files over the Model Context Protocol — so your skills are checked at the door (schema, security scanner, dedup, Ed25519 signature) and consistent across Claude Code, Cursor, Codex, and any other MCP host.

About Hosting AutoVault

This template runs AutoVault in remote MCP mode from the published GHCR image (ghcr.io/autoworks-ai/autovault). Railway provisions a 1 GB persistent volume mounted at /data/autovault for the SQLite database, signing key, and installed skills, then exposes the service over HTTPS on a *.up.railway.app domain. The server speaks Streamable HTTP MCP at /mcp, gated by OAuth 2.1 with PKCE — including dynamic client registration and refresh-token rotation, so any MCP-compatible agent can connect without a shared secret. On first boot, AutoVault seeds the owner account from the email and password you provide; on every subsequent boot it verifies the integrity of every stored skill against the on-disk signing key before serving it.

Common Use Cases

• Shared team skill vault — one AutoVault instance hosting the skills your whole team's agents reach for, so a fix to a skill propagates to everyone instantly without re-distributing files.
• Sandboxed or cloud-hosted agents — give agents that can't read a local filesystem (Claude Code on the web, hosted IDEs, CI runners) a remote MCP endpoint they can authenticate against.
• Multi-machine personal vault — keep your laptop, desktop, and any cloud workstation pulling from the same authoritative skill set with full audit history.

Dependencies for AutoVault Hosting

• A 1 GB persistent volume mounted at /data/autovault before the first deploy — the volume is what keeps your owner account, signing key, and skills durable across redeploys. Railway's template wiring handles this for you.
• An admin email and a strong password (12+ chars, randomly generated). The password is hashed at rest; there is no recovery path other than wiping /data/autovault and re-seeding.

Deployment Dependencies

• AutoVault repository on GitHub
• Documentation
• Deploy walkthrough
• Container image (ghcr.io/autoworks-ai/autovault)

Implementation Details

The service binds to Railway's injected $PORT and exposes:

• GET /healthz — liveness probe
• GET /.well-known/oauth-authorization-server — OAuth discovery
• POST /mcp — Streamable HTTP MCP (Bearer-token gated)

After the first deploy, verify end-to-end:

URL=https://.up.railway.app

curl -fsS "$URL/healthz" | jq
# → { "ok": true, "name": "autovault", "mode": "remote" }

git clone https://github.com/autoworks-ai/autovault.git && cd autovault
npm ci && npm run build
AUTOVAULT_REMOTE_URL=$URL \
  AUTOVAULT_ADMIN_EMAIL= \
  AUTOVAULT_ADMIN_PASSWORD= \
  npm run smoke:remote

A successful run prints === Remote smoke test completed ===.

Why Deploy AutoVault on Railway?

Railway is a singular platform with an intuitive interface, allowing for swift application development and deployment. By choosing Railway, you benefit from:

• Scalability and Flexibility: Adjust resources easily to match your application's evolving needs without the hassle of complex configurations.
• User-Friendly Setup: Forget about steep learning curves. Railway's interface is designed for both novices and seasoned developers.
• Cost-Effective Hosting: Optimize your spending with Railway's transparent and competitive pricing model.
• Robust Performance: Rely on Railway's infrastructure to ensure your application's high availability and performance.