Keep the Static sites build you already use
Bring generated files from a frontend framework or a plain static repository. Keep the build command and output path clear enough to reproduce from source.
Frontend apps · plans from $10/month
Deploy Static sites.Publish the built site.
Publish HTML, CSS, JavaScript, or a framework-generated static build from a small Nginx starter with routes, domains, TLS, and release state attached.
Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy
Candidate release
Static sites
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
NginxHTMLCSSJavaScriptSPAsStatic generators
The production path
A working Static sites project still needs a safe release.
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Promote the version that reports healthy
Serve the built files through the static template, verify root and fallback routes, and connect the promoted output to a generated or custom domain.
Trace production back to source
Build output, runtime logs, health state, secrets, domains, and the promoted release stay attached to the project instead of being split across unrelated tools.
From source to release
Three steps keep the deployment path reviewable.
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
- 01
Start with source or a template
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios login - 02
Review the deployment contract
Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yaml - 03
Deploy and inspect the result
Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios up
adios.yaml
Your projectname: docs-site
template: nginx:staticStart from the static template, then replace the example content or connect your framework's generated output.
Deployable starting points
Start Static sites from a template when the repository is not ready.
The Nginx static template includes a production serving configuration and SPA-style route fallback for a quick first deployment.
Web apps
Nginx Static
An Nginx starter for static HTML, CSS, JavaScript, and single-page apps.
HTMLNone
- Template key
- nginx:static
- Runtime
- nginx
- Repository
- templates
- Source path
- nginx/static
git clone https://github.com/adiosdotdev/templates.git
cd templates/nginx/static
adios upBefore production
Verify the workload.Then promote it.
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Ready when…
- The site output can be reproduced from source.
- The intended index file and asset paths exist.
- SPA routes have the required fallback behavior.
- No private credential is present in client files.
Preview when…
- The site assumes a different base path or hostname.
- Redirects, cache headers, or security headers are changing.
- The app actually requires server rendering or API routes.
Questions, answered
What to know before deploying Static sites.
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
Can Adios deploy an existing Static sites project?
Yes. Run the Adios CLI from the project root, keep the repository and dependency files you already use, and add an adios.yaml file that describes the production build, start command, port, and health path.
Do I need Docker to deploy Static sites?
Not for a standard supported runtime. Use the project's normal production commands in adios.yaml. If the build needs unusual operating-system packages or native libraries, verify those dependencies in a preview before promotion.
Which frameworks can produce a static site for this route?
React, Vue, Angular, Svelte, and many documentation or static-site generators can emit deployable files. Confirm the build output and client-route fallback for the chosen framework.
Can I connect a custom domain to a static site?
Yes. Verify the hostname, apply the instructed DNS records, and use managed TLS to serve the promoted static release over HTTPS.
What happens when the build or health check fails?
The candidate release keeps its build and runtime output for inspection. It must report healthy before it becomes the promoted version serving the application route.
Can I start from a template instead of an existing repo?
Yes. This page links to the closest official Adios Static sites starters. Inspect the exact source variant, deploy it in the console, or clone it locally and run adios up.
Related deployment paths
Connect the rest of the stack.
Deploy React
Build a React application from its existing repository, serve the generated output or production Node.js process, and connect the release to a stable HTTPS route.
Deploy Vue
Build a Vue application from its existing repository, serve the production output, verify client-side routes, and promote it to a managed HTTPS domain.
Deploy Angular
Build an Angular application with the committed workspace configuration, serve its browser output, verify route fallback, and promote it to a managed HTTPS domain.
Deploy Svelte
Build a Svelte or SvelteKit project with its chosen adapter, serve the emitted output, verify routes, and keep the production command attached to source.
The first release
Deploy Static sites with the source and evidence attached.
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.