Comparison Table
How Presets Work
Presets are stored in the database and seeded from code on startup. Each preset maps to:- A pre-built Incus image — Contains all packages pre-installed (e.g.,
instapods/nodejs) - A cloud-init configuration — Sets hostname, starts services, and configures networking
- A runtime definition — Defines available capabilities (log paths, reload commands, etc.)
Choosing a Preset
- Static — Best for HTML/CSS/JS sites, single-page apps, documentation sites. Files are served directly by nginx.
- PHP — Best for PHP applications, Laravel, WordPress alternatives. nginx handles HTTP, PHP-FPM processes PHP files.
- Node.js — Best for Express, Fastify, Next.js, or any Node application. Managed by systemd.
- Python — Best for Django, Flask, FastAPI, or any Python application. Managed by systemd with built-in venv.
- Go — Best for Go HTTP services and APIs (net/http, Gin, Echo, Fiber, chi) and background workers. Your code is compiled on the pod and systemd runs the resulting binary.
Runtime Versions
PHP, Node.js, Python, and Go presets support multiple runtime versions. Choose a version when creating a pod — from the dashboard’s version picker or with the CLI--version flag:
Compiled vs Interpreted
Go is the only preset that compiles. Static, PHP, Node.js, and Python all run your files as they are, so uploading a file changes what the pod serves immediately. On the Go preset, uploading source changes nothing until it is rebuilt — every deploy andpods reload runs go build and restarts the resulting binary.
If a Go build fails, the deploy fails and returns the compiler error, and your previous binary keeps running — a broken commit does not take your app down. See Go for details.
File Structure
All presets create a default userinstapod with the app directory at /home/instapod/app. This is where you deploy your code.
For PHP, the public root is /home/instapod/app/public — place your index.php there. Other files (like configuration, vendor directory) go in /home/instapod/app.