Static site boundary
Astro, Next.js static export, docs, landing pages, and content sites often fit static deployment. The key is that the output folder opens correctly, including deep links and asset paths.
Static site deployment fits already-built HTML/CSS/JS output. VPS/CLI deployment fits projects that need persistent processes, APIs, workers, cron, database connections, or service-level recovery paths.
Output folder
Is there a clear `dist/`, `out/`, or build output directory?
Server runtime
Does it depend on API routes, SSR, workers, cron, or a long-running process?
Secrets
Does it need database URLs, tokens, SSH keys, or provider credentials?
Health
Does it need health endpoints, process status, and logs?
Rollback
Does rollback need service state, not only replacing static files?
Astro, Next.js static export, docs, landing pages, and content sites often fit static deployment. The key is that the output folder opens correctly, including deep links and asset paths.
When a project needs a background process, port, Docker/Compose, database connection, or queue worker, do not pretend it is static. CLI/VPS paths preserve logs and recovery.
Many projects split cleanly: static frontend through static publishing, API/worker through VPS or self-hosted control plane. Internal links should send users to the matching deploy entrypoint.
If the output can be served directly by a static server, try the static site path first.
If server runtime is needed, use CLI/VPS or self-hosted deployment paths.
Static checks cover deep links/assets; service checks cover health/logs/status/rollback.
Static export can use static site deployment. Server runtime, API routes, or SSR should use service deployment.
Default static output fits static sites. SSR adapters or server logic should use service deployment.
It is fuller, but it gives logs, health, process status, and rollback paths for projects that truly need runtime.
Appaloft SEO pages are organized around real deployment tasks. Each page should lead to the next useful step, not stand alone.
Use checklists and choice pages to move search users to the right deploy entrypoint instead of abstract concepts.
Connect build output, browser upload, CLI deploy, and one-click buttons for static site publishing.
Tie the control plane, CLI, servers, rollback, and Cloud collaboration boundary into one self-hosting cluster.
Use GitHub Actions to connect repository events to Appaloft deployment while keeping explicit workflows.
Let the agent identify project shape first, then choose the skill, CLI, static publishing, or Cloud console path.