Build and deploy

Ludicord builds the Activity client and trusted server into one atomic production output. The same runtime serves static assets, authentication, API routes, and WebSocket upgrades from one origin.

#Create the production build

1npm run build

The build scans conventions, generates route declarations, checks route collisions and boundaries, compiles client and server graphs, reports large client assets, and writes .ludicord/ atomically. A failed build does not replace the last complete output with a partial one.

#Start the built runtime

1npm run start

start requires an existing compatible production build. It does not recompile source. Set PORT and HOST when the platform controls the listening address.

#Production environment

At minimum, provide the Client ID, Client Secret, Session Secret, and any verification values enabled by configuration. Add a bot token only for the extended Discord resources that require it.

1LUDICORD_DISCORD_CLIENT_ID=...
2LUDICORD_DISCORD_CLIENT_SECRET=...
3LUDICORD_SESSION_SECRET=...
4LUDICORD_DISCORD_PUBLIC_KEY=...

Use the hosting provider's secret store, not a committed .env.production file.

#Network requirements

The deployed origin must support:

• HTTPS for every Activity request;
• long-lived WebSocket upgrades on /ws/*;
• cookies on Ludicord auth routes;
• the configured maximum request and WebSocket payloads;
• graceful process shutdown;
• one consistent public hostname used by the Discord URL mapping.

If a reverse proxy terminates HTTPS, forward the correct host and protocol and preserve WebSocket upgrade headers.

#Update Discord URL mappings

Replace the development tunnel target with the production hostname. Keep the root mapping pointed at the Ludicord origin unless you deliberately proxy additional prefixes.

The target is a hostname without https:// in Discord's mapping UI.

#Scale safely

API routes can use a shared database or service normally. Built-in WebSocket room membership and shared Activity state are process-local. When running multiple server processes, either keep an Activity instance sticky to one process or move authoritative state and fan-out into shared infrastructure.

Do not depend on local filesystem writes for durable production state. A deployment can replace or restart the process at any time.

#Release checklist

1. Run the production build from a clean dependency installation.
2. Start the built output and verify the health endpoint.
3. Test OAuth2 in a production Discord launch.
4. Confirm an authenticated API request.
5. Confirm WebSocket connect, event, reconnect, and shutdown behavior.
6. Verify mobile safe areas and the minimized surface.
7. Check that source maps, environment files, and credentials are not publicly served.
8. Update the Discord URL mapping only after the new origin is ready.

#Safe production errors

Development panels include source locations to help the developer. Production responses and pages avoid exposing project file paths, source frames, environment values, or internal stacks. Keep application error responses equally restrained.

#Next step

Use the API reference as a capability map while building larger features, then add the CLI checks your release process needs.