Deploy

Build

Run vite build to build your application into dist/. Vite will build both the client and server builds, then domco will prerender any static routes and run the adapter if set.

dist/
├── client/
│	├── (_immutable/) - any JS/CSS/immutable assets
│	└── (index.html) - prerendered pages
└── server/
	├── func.js - server entry point
	└── (adapter-entry.js) - if using an adapter

Manual deployment

If you are not using an adapter, you can import handler from the func.js module and configure your func to use in another environment.

The dist/client/ directory holds client assets. JS and CSS assets with hashed file names will be output to dist/client/_immutable/, you can serve this path with immutable cache headers. Other assets like prerendered HTML files are processed and included in dist/client/ directly.

Node server

Here’s an example of how to serve your application using the result of your build with node:http, sirv, and domco/listener.

// server.js
// import the `handler` from the build output
import { handler } from "./dist/server/func.js";
// converts web handler to a Node compatible request listener
import { nodeListener } from "domco/listener";
import { createServer } from "node:http";
// `sirv` serves static assets
import sirv from "sirv";

const assets = sirv("dist/client", {
	etag: true,
	setHeaders: (res, pathname) => {
		// serve `dist/client/_immutable/*` with immutable headers
		if (pathname.startsWith("/_immutable/")) {
			res.setHeader("Cache-Control", "public, max-age=31536000, immutable");
		}
	},
});

const server = createServer((req, res) =>
	// first, look for a static asset
	assets(req, res, () =>
		// fallthrough to the handler if static asset is not found
		nodeListener(handler)(req, res),
	),
);

server.listen(3000);

Run this module to start your server and navigate to http://localhost:3000/ to view your application.

node server.js

Adapters

Add a deployment adapter within your Vite config to output your application to a different target with no additional configuration.

Example

// vite.config
import { domco } from "domco";
// import adapter
import { adapter } from "domco/adapter/vercel";
import { defineConfig } from "vite";

export default defineConfig({
	plugins: [
		domco({
			// add to your domco config
			adapter: adapter({
				// options...
			}),
		}),
	],
});

Cloudflare

The Cloudflare adapter outputs your application to run on Cloudflare Pages.

• Function runs on workerd.
• Outputs public assets to be served on Cloudflare’s CDN.

Deno

The Deno adapter outputs your application to run on Deno Deploy. You do not have to use Deno to build your func to use this adapter.

• Function runs on Deno.
• Static files are served with @std/http/file-server.

Vercel

The Vercel adapter outputs your application to the Build Output API specification.

• Function runs on Node.js, Node.js with ISR, or Edge Runtime.
• Outputs public assets to be served on Vercel’s Edge Network.
• Supports on demand Image Optimization when configured in the adapter config. Set the src attribute of an image using the /_vercel/image/... optimized URL format. In dev and preview modes, domco will redirect to the original image.

Creating an adapter

If you’d like to deploy a domco application to a different provider, and you need many configuration steps for this to take place you can create an adapter.

Check out the current adapters to see how to make your own.

Adapters take care of these deployment steps.

1. Set ssr options if changes are needed, for example if you are deploying to an edge function, set this to "web worker".
2. Create an entry point for the target environment by using the handler from dist/server/func.js. This could be reexporting it as a different export, or applying to a node server.
3. Within the entry point, serve the dist/client/* directory as static assets, and the dist/client/_immutable/* directory with immutable cache headers. Static assets must be hit before the handler to take advantage of prerendering. When an asset is not found, the request needs to fallthrough to the handler.

If you think others might benefit from your adapter you can create an issue or pull request to propose a new adapter. Adapters should be created for zero configuration deployments for deployment providers, not specific to JavaScript runtimes.