Nstack: A full-stack app system for the AI web

Nikita Rykov — Tue, 07 Jul 2026 03:14:24 +0000

I do not want every full-stack app to invent its own shape.

That sounds obvious until the project has a backend, a frontend, generated API clients, Dockerfiles, secrets, environments, databases, caches, object storage, cron jobs, deploy targets, logs, backups, rollbacks, and AI agents editing the repo.

At that point, the framework choice is only one part of the system. The product is the workflow that keeps all of those pieces understandable.

That is what I built with nstack.

nstack is an opinionated full-stack app system for:

Encore.ts backend
Nuxt frontend
Dokploy deployment
pnpm workspace
AI-ready repo guidance

It creates the app, runs it locally, keeps the typed frontend client in sync, maps backend resources to deployable infrastructure, manages targets and secrets, deploys to Dokploy, and gives coding agents clear project rules.

The first run is short:

curl -fsSL https://nstack.tech/install.sh | bash
nstack init my-app
cd my-app
nstack setup
nstack dev

The short command surface is possible because the stack has one known shape.

The stack is opinionated on purpose

Encore and Nuxt were chosen because they already make strong decisions.

Encore keeps APIs and backend resources close to the code. Nuxt gives the frontend a clear app structure, SSR support, routing, and a practical production server. Dokploy gives the deployment a concrete target: services, domains, logs, resources, schedules, and Compose apps on a server you control.

Those opinions help human developers because fewer decisions have to be remade in every repo. They also help AI agents because the project has stable places for APIs, frontend pages, generated clients, deploy output, local state, and instructions.

The point is not to support every possible stack. The point is to make one full-stack path deep enough that the tooling can be useful.

What nstack creates

A generated app looks like this:

my-app/
  backend/
    api/
      status.ts
      db.ts
      gateway.ts
    encore.app
  frontend/
    app/
      pages/index.vue
      utils/api.ts
    nuxt.config.ts
  deploy/nstack/
  nstack.config.mjs
  pnpm-workspace.yaml
  AGENTS.md
  NSTACK_GUIDELINES.md

The backend is Encore.ts. The frontend is Nuxt. The root config describes the nstack app and deployment shape. deploy/nstack/ contains generated deployment output. AGENTS.md and NSTACK_GUIDELINES.md explain the project to coding agents and humans working in the repo.

The generated app is meant to be edited as a normal app. The system exists so the surrounding workflow is consistent.

Local DX is owned by the system

nstack setup prepares a fresh clone. It installs dependencies, bootstraps pnpm through Corepack when needed, installs the Encore CLI when it is missing, and checks Docker only when the declared Encore resources need it.

nstack dev starts the Encore backend, the Nuxt frontend, and generated client sync.

nstack dev

When the backend API surface changes, nstack regenerates the Encore TypeScript client used by the Nuxt app. Frontend code imports through frontend/app/utils/api.ts, so browser, SSR, and deployed URLs are handled in one place.

The normal project scripts use the same path:

pnpm dev
pnpm check
pnpm build

On a fresh clone, those commands reuse nstack setup and client sync instead of assuming the machine already has the right tools.

Infrastructure comes from backend code

Encore lets the backend declare durable resources in source. nstack uses that metadata to prepare Dokploy deployment state.

When backend code declares SQL databases, caches, Pub/Sub topics, object buckets, cron jobs, and secrets, nstack deploy reads that shape and maps it to deployable infrastructure.

Encore SQL database -> Dokploy Postgres
Encore cache -> Dragonfly
Encore Pub/Sub -> NSQ
Encore object bucket -> RustFS
Encore cron metadata -> Dokploy schedules
Encore secrets -> target-specific environment values

The deploy artifacts are rendered into deploy/nstack/:

deploy/nstack/encore.infra.json
deploy/nstack/compose.dokploy.yaml

You change the app or nstack.config.mjs, then run the CLI. The generated files reflect the app shape.

Deploy is part of the app workflow

nstack deploy does the full Dokploy handoff.

nstack deploy

It discovers Encore resources, renders Encore infra config, renders Dokploy Compose, provisions resources, configures domains and Traefik routes, syncs schedules, deploys the app, verifies the public URL, and prints the result.

The default build mode lets Dokploy build the backend and frontend from source using production Dockerfiles and Compose build: sections. You can deploy without setting up GHCR, Docker Hub, or another image registry.

For source-backed apps, nstack can configure Dokploy source deployments for GitHub, GitLab, Bitbucket, and Gitea or Forgejo when that provider is connected in Dokploy. Provider-backed deploys can use native push webhooks for deploy-on-push.

Targets and operations are first-class

Apps often need production, staging, and other environments. nstack calls those targets.

nstack target create staging --domain staging.example.com
nstack deploy --env staging

Each target can have its own domain, secrets, resources, and local state. Runtime secrets move through nstack commands:

nstack env set API_SECRET
nstack env push
nstack env pull --all

The operational commands live beside the app too:

nstack status
nstack logs --follow
nstack backup
nstack rollback
nstack pull
nstack doctor
nstack undeploy --yes
nstack cleanup

Backups include Dokploy and app metadata, remote Compose environment values, and data artifacts for stateful resources such as Postgres, cache volumes, RustFS object storage, and NSQ Pub/Sub data. Destructive deletion paths create a critical backup first unless that guard is explicitly disabled.

AI guidance is generated with the app

AI agents work better when the repo tells them what matters.

nstack generated apps include AGENTS.md and NSTACK_GUIDELINES.md. Those files describe the project map, generated files, commands, frontend API client, deploy model, resource rules, secret handling, target behavior, and recovery commands.

They also point agents at the correct dev workflow.

nstack devexec 'await apiJson("/status")'

devexec starts a temporary dev stack, runs one script, and exits. That gives agents a reliable way to test backend and frontend behavior without leaving a long-running server behind.

For frontend checks, it can capture screenshots:

nstack devexec 'return await screenshot("/", { width: 390, height: 844 })'

Under AI coding harnesses, nstack dev refuses to start a long-running dev server by default. Agents use devexec for repeatable checks, and humans can still run the normal dev server.

The product is the shared shape

Calling nstack a deployment wrapper misses the point.

The value is the full project shape: the backend model, frontend client flow, local commands, generated deploy output, Dokploy resource mapping, target state, operational commands, and AI guidance all fit together.

That is why the stack is narrow. nstack can be useful because it knows what kind of app it is managing.

Try it

curl -fsSL https://nstack.tech/install.sh | bash
nstack init my-app
cd my-app
nstack setup
nstack dev

Docs are at nstack.tech.

DEV Community: Nikita Rykov