Altien ships Mike as one container

The fork collapses Mike's two halves into a single deployable image, with one knob to switch between same-origin and split-origin setups.

infrastructure

Most Mike deployments run the backend and frontend as separate services. Altien's fork bundles them into one container image - frontend, backend, and the document-conversion tooling needed to handle Word files, all baked together. A single build argument decides whether the frontend talks to the backend on the same domain or a separate one, so the same image source can serve both deployment shapes.

It's an opinionated choice. You give up the flexibility of scaling the two halves independently, but you get a much simpler thing to hand to ops: one image, one place to deploy, one set of environment variables to document. The fork also trims the frontend's required configuration down to a near-minimum, which suggests the team is optimising for legal-ops teams who want to stand Mike up without a platform engineer on standby.

So what Worth a look if you're evaluating Mike for a small in-house team or a single-tenant private deployment where simplicity beats elasticity.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from Altien/mikeOssAzure, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`d829a171`	feat(build): bundled multistage Dockerfile + static export config	Allen Morgan	2026-05-08	↗ GitHub
commit body Single image for the application: Next.js builds the frontend as a static export and the Dockerfile copies the resulting /out tree into the backend image's /app/public. The Express server picks it up at runtime when the directory is present (see the static-frontend block in backend/src/index.ts). * Dockerfile - three stages: backend-deps : install + tsc + tree-shake the backend frontend-deps : install + next build with NEXT_PUBLIC_API_BASE_URL passed in via --build-arg so the same image source can target same-origin or split-origin deployments runtime : node:lts-alpine + libreoffice (for docx convert) with the built backend, prod node_modules, and the frontend export. * .dockerignore - excludes backend test fixtures, migrations directory artefacts, the frontend's .next/ debug output, and anything under .claude/. * frontend/next.config.ts - output: "export" so the frontend produces a static SPA bundle that the backend can serve out of a single Express process. * frontend/.env.local.example - documents the new minimal env surface: only NEXT_PUBLIC_API_BASE_URL plus the optional supabase-mode pair. * frontend/package.json + lockfile - bumps the dep set to match the updated context + lazy-supabase shape; resend dropped (unused).
`feec6d3e`	fix(build): add scripts/install/README.md placeholder	Allen Morgan	2026-05-08	↗ GitHub
commit body The runtime stage of the Dockerfile unconditionally COPYs scripts/install, but that directory was not present in the OSS fork, so `az acr build` (and any plain `docker build`) failed at "COPY failed: file not found in build context" before runtime was reached. The application code in backend/src/routes/install.ts already expects this directory may be empty or absent when the OSS image is built without the marketplace deploy bundle. The runtime route checks fs.existsSync and degrades cleanly. The Dockerfile was the mismatch. This commit ships an empty-by-design placeholder README so the COPY succeeds. Downstreams that bundle their own operator scripts drop them alongside this README without Dockerfile changes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-199.md from inside the repo you want the changes in.

⬇ Download capture-thread-199.md