A modern adapter for SvelteKit apps that generates a standalone Bun server.
This is basically ported from svelte-adapter-bun.
env
parsing and validationInstall with bun add -d svelte-adapter-bun-next
, then add the adapter to your svelte.config.js
:
// svelte.config.js
import adapter from "svelte-adapter-bun-next";
export default {
kit: {
adapter: adapter(),
},
};
After building the server (vite build
), use the following command to start:
# go to build directory
cd build/
# run Bun
bun run start
The adapter can be configured with various options:
// svelte.config.js
import adapter from "svelte-adapter-bun-next";
export default {
kit: {
adapter: adapter({
out: "build",
// precompress: true,
precompress: {
brotli: true,
gzip: true,
files: ["htm", "html"],
},
}),
},
};
The directory to build the server to. Default: build
— i.e. bun run start
would start the server locally after it has been created.
Enables precompressing using gzip and brotli for assets and prerendered pages. Default: false
.
Enable brotli precompressing. Default: false
.
Enable gzip precompressing. Default: false
.
This enables bun's error page. Default: false
Bun automatically reads configuration from
.env.local
,.env.development
and.env
. (Documentation)
Full schema is defined in env.ts
, parsed and validated using t3-env
and zod
.
PORT
and HOST
Specify the port and host to listen on.
Default: 0.0.0.0
, 3000
BODY_SIZE_LIMIT
The maximum request body size to accept in bytes including while streaming.
Accepted inputs:
1048576
.K
, M
, G
), e.g. 1M
."Infinity"
or number 0
to disable body size limit.Default: 512K
ORIGIN
, PROTOCOL_HEADER
and HOST_HEADER
HTTP doesn't give SvelteKit a reliable way to know the URL that is currently being requested. The simplest way to tell SvelteKit where the app is being served is to set the ORIGIN
environment variable.
With this, a request for the /stuff
pathname will correctly resolve to https://my.site/stuff
. Alternatively, you can specify headers that tell SvelteKit about the request protocol and host, from which it can construct the origin URL.
x-forwarded-proto
andx-forwarded-host
are de facto standard headers that forward the original protocol and host if you're using a reverse proxy (think load balancers and CDNs). You should only set these variables if your server is behind a trusted reverse proxy; otherwise, it'd be possible for clients to spoof these headers.
Default: http://localhost:3000
, X-Forwarded-Proto
, X-Forwarded-Host
DEV_MODE
This enables bun's error page.
Default: false