Our own products run on the same components, the same deploy script, and the same agentic foundation we'd build into yours. Everything below is live. The MCP endpoint is public — point any client at it.
Each one is built on the same components. None of them are demos — we operate them in production.
luwi.devMarketing + ops consoleThis site, plus the /ops operator dashboard (PM2 widget, Docker widget, agent settings, ticket triage). Next.js Pages Router on PM2, single-process. No CMS.
Open ↗vdo.luwi.devImage / video studioA branded fork of an upstream open-source generative-AI UI, hardened with our overlay + brand-drift defense. Bearer-gated. Powers our agentic image pipeline.
Open ↗vdo.luwi.dev/mcpPublic MCP endpointStreamable-HTTP MCP server. 31 tools across 6 families (vdo · brevo · sim · paperclip · hermes · ops). Bearer-auth. Real handshake — any MCP client connects.
Open ↗agents.luwi.devPaperclip board · ticket triageIssue tracker that our Support Triage agent reads and writes through the paperclip_* MCP family. Same tools you would get if we built a triage layer for your team.
Open ↗None of these are bumper stickers — each maps to a thing in the repo or on the box.
One VPS, Docker-compose, PM2, nginx. No Kubernetes cosplay until the load actually demands it. Block-storage volume for growth, system disk stays lean. Idempotent deploys with auto-rollback on /api/hello.
We track upstream open-source (e.g. the image-studio base) and overlay our brand + auth. We fork when the upstream architecture blocks something we need — multi-tenant, custom auth, on-prem flags. A `diff-upstream.sh` script makes the trade-off visible quarterly.
When you overlay an upstream, the build will silently re-introduce their wordmark someday. We run a three-phase brand-checks script — pre-overlay informational, rebrand strict verify-then-replace, post-build strict on brand strings — that fails the build instead of shipping a regression.
Our MCP server boots bearer-only and registers each tool family only when its credential is present. No big-bang config. A missing key disables one family — the others keep working. Same pattern we ship to clients.
Persisted secrets sit in a 0600 root-owned JSON on the VPS, mirrored into process.env at boot. The /ops/settings panel writes through a single endpoint. Rotation is a one-line restart.
The repeated patterns across our products and client work. Boring, named, documented.
git push → SSH → pull, build, PM2 reload, rsync agentic, rebuild changed containers. If /api/hello fails the post-deploy check, the previous build is restored automatically. nginx vhost edits stay manual on purpose.
A single writer (/api/admin/agentic-config) is the only thing that touches the secrets JSON. The container loader (lib/agentic/persisted-config.ts) mirrors it into env at boot. UI changes → file change → container restart → live.
The ops dashboard probes each service through a single /api/agentic/health endpoint that fans out to PM2, Docker, and the MCP container. One request, one aggregated view. The ActionCenter raises a card per blocker — never a wall of green checks.
Docker data-root, app data, PostgreSQL, backups, and dev clones all live on a block-storage volume — not the system disk. Auto-rotated PM2 logs. A documented "where does new growth go" rule that survives the team growing.
Stable cores, vendored carefully, replaceable when they stop earning their keep.
If you're building an agentic system and the words above sounded familiar, we should talk. We do custom builds when the products don't fit as-is.