Framework Detection

When you connect a GitHub repository, Stackpad analyzes your project to detect the framework and configure the build automatically. No Dockerfile or build configuration is needed for supported frameworks.

Supported frameworks

Framework	Detection	Default port
Next.js	next in dependencies + next.config.*	3000
Remix	@remix-run/node in dependencies	3000
Astro	astro in dependencies	4321
Nuxt	nuxt in dependencies	3000
SvelteKit	@sveltejs/kit in dependencies	3000
Express	express in dependencies	3000
Hono	hono in dependencies	3000
Static site	No server framework detected	80

How detection works

Stackpad reads your package.json (and framework-specific config files like next.config.js) to determine:

1. Framework type — which build strategy and Dockerfile template to use
2. Package manager — from the lockfile (pnpm-lock.yaml, yarn.lock, or package-lock.json)
3. Build command — from the build script in package.json
4. Start command — from the start script or framework defaults
5. Output mode — server-rendered or static

Next.js specifics

For Next.js applications, Stackpad detects:

• Standalone output mode (recommended) — if output: 'standalone' is set in next.config.js, Stackpad uses it for a smaller image
• Default output — if standalone isn’t configured, the full .next directory is used
• Static export — if output: 'export' is set, the app is served as a static site

Tip

For the best deployment performance with Next.js, add output: 'standalone' to your next.config.js. This creates a minimal production bundle.

Static sites

If no server framework is detected, Stackpad treats your project as a static site. It looks for build output in common directories:

• dist/
• build/
• out/
• public/

The static files are served with a lightweight web server.

Monorepo support

Stackpad detects pnpm workspaces and lets you specify a root directory for your service. When a root directory is set:

• Dependencies are installed from the workspace root
• The build runs in the specified directory
• Only the relevant package is included in the final image

Nixpacks (universal fallback)

For languages and frameworks not covered by the JavaScript-specific detection above, Stackpad uses Nixpacks as a universal build system. Nixpacks automatically detects your language, installs dependencies, and builds an optimized Docker image — no Dockerfile needed.

Supported languages via Nixpacks

Language	Detection
Laravel / PHP	composer.json with laravel/framework
Python	requirements.txt, pyproject.toml, or setup.py
Go	go.mod
Ruby	Gemfile
Rust	Cargo.toml
Java	pom.xml or build.gradle
Elixir	mix.exs
Zig	build.zig
C#	.csproj or .sln
F#	.fsproj

And more — Nixpacks supports 20+ languages total.

How it works alongside framework detection

1. Stackpad first checks for JavaScript frameworks (Next.js, Remix, etc.)
2. If no JavaScript framework is detected, Nixpacks analyzes the project
3. Nixpacks determines the language and generates an optimized build pipeline
4. The result is a Docker image deployed just like any other Stackpad service

Laravel

Laravel projects are fully supported:

• Auto-detected from composer.json with laravel/framework
• PHP, Composer, and npm assets are handled automatically
• Default start command: php artisan migrate --force && php artisan serve --host=0.0.0.0 --port=8000

Custom Dockerfiles

If auto-detection doesn’t fit your needs, you can use a template to deploy pre-configured stacks for popular software.

What’s next?

• Git push deploy — understand the full deployment pipeline
• Supported frameworks — complete list of supported frameworks and languages
• Templates — deploy pre-configured stacks for popular software