Deploy Drawnix | (Just Updated) Open-Source Whiteboard, Mind Map and Flowchart Editor, Excalidraw Alternative
Drawnix open-source whiteboard: mind maps, flowcharts, infinite canvas
Just deployed
Deploy and Host Drawnix on Railway
Built for an LLM agent to deploy and use. The deploy form has no fields and nothing to configure. Drawnix is an open-source whiteboard: infinite canvas, free drawing, mind maps, flowcharts, shapes and images, built on the Plait framework (MIT). It runs entirely in the browser, so a deploy gives a team a private, always-on whiteboard at its own URL with no account and no database.
This template runs Drawnix v0.4.1 from a wrapper image over the official pubuzhixing/drawnix image, pinned by digest. People use it as a self-hosted Excalidraw or draw.io alternative for sketches, architecture diagrams, mind maps and meeting boards.
About Hosting Drawnix
Drawnix is a static web app: the server only delivers files, and every drawing lives in the browser of the person who made it (autosaved to local storage, exported as a .drawnix file, PNG, SVG or JSON). That is why the template has no volume and no variables: there is no server-side state to lose on a redeploy. The upstream image serves from a shell-less busybox server on a fixed port 80, which cannot follow Railway's injected PORT. The wrapper copies the built site into nginx instead, which listens on PORT over IPv4 and IPv6, compresses the JavaScript bundles (1.4 MB to 0.45 MB for the largest), caches content-hashed assets for a year, answers /healthz and falls back to the app shell for unknown paths. The canonical and hreflang tags that point at drawnix.com are removed from the page, so your copy does not name another site as its canonical.
There is no login. Anyone who has the URL can open the whiteboard, so keep the domain private or put an authenticating proxy in front of it if the boards are sensitive.
Agent contract
- Public URL:
https://RAILWAY_PUBLIC_DOMAIN(the generated domain of thedrawnixservice) - Private URL:
http://drawnix.railway.internal:8080 - Credentials: none; the service has no accounts and no variables
- Auth: none. Drawings are stored in the user's browser, never on the server, so no request to this service changes server state.
- Health:
GET /healthzreturns 200 with the bodyok
# needs: SITE_URL, the public https URL of the drawnix service
curl -s -o /dev/null -w "health: %{http_code}\n" "$SITE_URL/healthz"
curl -s "$SITE_URL/healthz"
curl -s -o /dev/null -w "app shell: %{http_code} %{content_type}\n" "$SITE_URL/"
curl -s "$SITE_URL/" | grep -c "Drawnix"
ASSET=$(curl -s "$SITE_URL/" | grep -o '/assets/[^"]*\.js' | head -1)
curl -s -H 'Accept-Encoding: gzip' -o /dev/null -w "bundle: %{http_code} %{content_type} gzip-bytes=%{size_download}\n" "$SITE_URL$ASSET"
curl -s -o /dev/null -w "unknown path: %{http_code}\n" "$SITE_URL/does-not-exist"
# write-auth: none - static site, no write endpoint; drawings are saved in the browser, not on the server
A fresh deploy prints health: 200, ok, app shell: 200 text/html, a count of lines mentioning Drawnix (1 or more), a bundle: 200 application/javascript line with a gzip byte count, and unknown path: 200 (the app shell answers unknown paths, as a single-page app should).
Why Deploy Drawnix 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 Drawnix 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.
- Agent-ready - no deployer fields, a contract block and one script an agent can run to confirm the app is up.
- Nothing to lose - no database and no volume; a redeploy cannot damage a drawing, which lives in the browser.
- Light - one nginx container, measured about 3 MiB idle.
- Fast first load - gzip on the JavaScript bundles and a one-year cache on hashed assets.
- Health-checked - Railway restarts the service if it stops answering
/healthz.
Common Use Cases
- Team whiteboard - a private, self-hosted canvas for sketching and meetings.
- Architecture and flow diagrams - flowcharts and diagrams that export to PNG, SVG or JSON.
- Mind mapping - brainstorms and outlines on an infinite canvas.
- Embedded drawing tool - link to it from docs, wikis or internal tools.
Dependencies for Drawnix Hosting
- None. A custom domain is optional.
Deployment Dependencies
Template Content
