Forem: qaynam

How to Deploy a SvelteKit App to Cloudflare Containers

qaynam — Sun, 04 Jan 2026 13:50:35 +0000

What Is Cloudflare Containers, the “Dream Service”

Cloudflare Containers is a container service recently released by Cloudflare in beta. From a user’s perspective, it feels similar to Cloud Run, but with the ability to directly invoke, start, and shut down containers from Workers. Since it is container-based, there are effectively no runtime restrictions.

Overview · Cloudflare Containers docs

Run code written in any programming language, built for any runtime, as part of apps built on Workers.

developers.cloudflare.com

What’s Good About It

Workers are excellent, but they come with many limitations and often feel like they don’t quite reach the itchy spots. Nowadays, standard Node.js APIs are available, making them far more usable than before. Still, due to their edge nature, there are memory limits and execution time limits. Trying to run an entire application using only Cloudflare Workers can be challenging in some scenarios.

That’s where Cloudflare Containers come in. Heavy or long-running tasks can be offloaded to Containers, where they can run for an extended period and eventually return results. Lighter processing can be handled entirely within Workers. This separation significantly improves the overall developer experience.

Running SvelteKit on Cloudflare Workers

Because SvelteKit follows Web Standards, you can easily deploy it to Cloudflare Containers or Pages (now deprecated) using an adapter.

svelte.dev

What We Want to Achieve This Time

We assume an application that is already running on Cloudflare Workers. When a request hits a specific endpoint, a Container is launched to perform heavy processing and ultimately return a response.

(In practice, Workers still have execution time limits. If you wait for the Container to finish, the Worker execution will be forcibly terminated. So the idea is to return a response immediately, let the Container do its work, and then perform further processing inside the Container.)

To achieve this, the Worker and the Container share the same codebase. The Worker is built with adapter-cloudflare, while the Container is built with the Node adapter.

The Problem

To run Cloudflare Containers, you must use Durable Objects.

If you are only running SvelteKit on Workers, there is no particular issue. You can bind R2, D1, and similar services directly and they will work as expected. However, once Durable Objects are involved, things change. The reason is that adapter-cloudflare does not support Durable Objects.

✘ [ERROR] Your Worker depends on the following Durable Objects, which are not exported in your entrypoint file: Container.

  You should export these objects from your entrypoint, .svelte-kit/cloudflare/_worker.js.

What to Do

Since there is no choice but to write a custom adapter, we extend adapter-cloudflare and create our own wrapper adapter.

More specifically, we create DurableObject.server.ts and define the Durable Object class there. We transpile only that file on its own and then inject the generated code into _worker.js, which is the SvelteKit build output. In short, this is handled via a workaround.

Let’s Get Started

First, the things required to run Cloudflare Containers are:

A Dockerfile
wrangler.jsonc (or toml) configuration

Creating the Dockerfile

Let’s start with the Dockerfile.

FROM node:24-slim

WORKDIR /app

# First, copy only dependency files
COPY package.json package-lock.json ./

# Copy the entire project source code and configuration files
COPY . .
RUN rm -rf node_modules 
# 👆 You must either keep this or add node_modules to .dockerignore,
#    otherwise you may encounter esbuild binary errors (this was a gotcha)

# This allows Docker layer caching to work efficiently
RUN npm ci

ENV ADAPTER=node
# 👆 Defined so svelte.config.js can determine the environment

ENV PORT=8080
# Perform a production build once
RUN bun run build:node

EXPOSE 8080

CMD ["npm", "run", "dev:node"]

// omitted
"scripts": {
    "dev:node": "ADAPTER=node vite dev --host 0.0.0.0 --port 8080"
}
// omitted

Adding Configuration to wrangler.json

Next is the wrangler.jsonc configuration.

{
    "$schema": "node_modules/wrangler/config-schema.json",
    "name": "http2",
    "main": "src/index.ts",
    "compatibility_date": "2025-04-03",
    "migrations": [
        {
            "new_sqlite_classes": [
                "Container"
            ],
            "tag": "v1"
        }
    ],
    "containers": [{
        "image": "./Dockerfile",
        "class_name": "Container",
        "max_instances": 2
    }],
    "durable_objects": {
        "bindings": [
            {
                "class_name": "Container",
                "name": "CONTAINER"
            }
        ]
    },
    "observability": {
        "enabled": true
    }
}

The migrations, containers, and durable_objects settings are required. In addition, the class_name defined in durable_objects, the class_name in containers, and the name in new_sqlite_classes must all match.

This part was based on the example repository:

https://github.com/cloudflare/containers-demos/blob/main/http2/wrangler.jsonc

Defining DurableObject.server.ts

In the example, the Durable Object is extended directly.

https://github.com/cloudflare/containers-demos/blob/main/http2/src/index.ts

There is actually a package called @cloudflare/containers, which allows you to write this more cleanly, so we’ll use that here.

https://github.com/cloudflare/containers

We define it under lib.

lib/DurableObject.server.ts

import { Container as CFContainer } from '@cloudflare/containers';
import type { Env } from '../worker-configuration';
import type { env as svEnv } from '$env/dynamic/private';
import type { env as svPublicEnv } from '$env/dynamic/public';

export class Container extends CFContainer<Env> {
    defaultPort = 8080;
    sleepAfter: string | number = '10m';
    enableInternet = true;

    startAndWaitForPorts(
        portsOrArgs?: number | number[] | Record<any, any>,
        cancellationOptions?: unknown,
        startOptions?: unknown
    ): Promise<void> {
        // Configure cancellationOptions with increased timeout values
        const enhancedCancellationOptions = {
            instanceGetTimeoutMS: 30000,
            portReadyTimeoutMS: 60000,
            waitInterval: 500,
            ...(cancellationOptions ?? {})
        };

        // @ts-expect-error Ignore for now due to type mismatch
        return super.startAndWaitForPorts(portsOrArgs, enhancedCancellationOptions, startOptions);
    }

    constructor(ctx: DurableObjectState<{}>, env: Env & typeof svEnv & typeof svPublicEnv) {
        super(ctx, env);
        this.envVars = {
            ...this.envVars
            // You can spread environment variables here
        };
        this.entrypoint = env.APP_MODE !== 'development' ? ['node', 'build'] : undefined;
        // Since the entrypoint can be overridden,
        // you can switch between prod and dev depending on the environment
    }

    async fetch(req: Request) {
        return super.fetch(req);
    }
}

Some settings are overridden, but it should work even without these changes.

Creating a Custom Adapter

This time the logic is not very complex, but there is official documentation on how to write a custom adapter, so it’s worth checking out.

svelte.dev

adapters/custom-adatper.js

import { readFileSync, writeFileSync } from 'node:fs';
import { join } from 'node:path';
import { execSync } from 'child_process';
import cloudflareAdapter from '@sveltejs/adapter-cloudflare';

export default function customAdapter(options = {}) {
    const baseAdapter = cloudflareAdapter(options);

    return {
        name: 'custom-cloudflare-adapter',
        async adapt(builder) {
            await baseAdapter.adapt(builder);
            await addDurableObjectDef(builder);
        },
        supports: baseAdapter.supports,
        emulate: baseAdapter.emulate
    };
}

async function addDurableObjectDef(builder) {
    const __dirname = new URL('.', import.meta.url).pathname;
    execSync(
        'tsc src/lib/DurableObject.server.ts --outdir ./dist --target esnext --module esnext --noResolve --noCheck'
    );
    console.log('Built Durable Object definitions');

    const dbPath = join(__dirname, '../', 'dist/DurableObject.server.js');
    const workerPath = join(builder.getBuildDirectory('cloudflare'), '_worker.js');

    try {
        let content = readFileSync(workerPath, 'utf-8');
        const durableObjectDefs = readFileSync(dbPath, 'utf-8');
        content = content + '\n' + durableObjectDefs;
        writeFileSync(workerPath, content);
        builder.log.info('Added Durable Object exports');
    } catch (error) {
        throw new Error(`Failed to add hooks import: ${error.message}`);
    }
}

What this does is simple: as described above, it builds DurableObject.server.ts on its own and appends its contents to _worker.js.

Use the custom adapter in svelte.config.js.

import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';
import customAdapter from './adapters/custom-cloudflare-adapter.js';
import nodeAdapter from '@sveltejs/adapter-node';

const config = {
    preprocess: vitePreprocess(),
    kit: {
        adapter:
            process.env.ADAPTER === 'node'
                ? nodeAdapter({
                        out: 'build',
                        precompress: true
                    })
                : customAdapter()
    }
};

export default config;

Note:
The main application runs on the Worker runtime, while the same application runs on the Node runtime inside the Container. For that reason, the Node adapter is also required here.

npmjs.com

Try building the custom adapter once.
Run ADAPTER=worker vite build and check that the Container definition code has been appended at the end.

Running the Dev Server

The Vite dev server does not seem to support Durable Objects yet, so you can only run this via wrangler.

To run a dev server, you need to use wrangler dev, but HMR does not work with it. As a result, you need to split your terminal: run vite build --watch in one, and wrangler dev in the other.

ADAPTER=worker npm run build

Then:

npx wrangler dev --port 5173

If things work correctly, Docker image downloads should start.

Sending a Request to the Container

First, define the binding types.

src/app.d.ts

import type { Container } from '$lib/DurableObject';
import { KVNamespace } from '@cloudflare/workers-types';

declare global {
    namespace App {
        interface Locals {}
        interface Platform {
            env: {
                CONTAINER: DurableObjectNamespace<Container>;
            };
            cf: CfProperties;
            context: ExecutionContext;
        }
    }
}

As a test, create routes/api/dev/+server.ts and call the Container from there.

routes/api/dev/+server.ts

import { json } from '@sveltejs/kit';

export const GET = async ({ platform }) => {
    try {
        const res = await platform?.env.CONTAINER
            .get(platform?.env.CONTAINER.idFromName('unique-name'))
            .fetch(
                new Request('http://localhost/api/dev/container', {
                    method: 'POST',
                    headers: { 'Content-Type': 'application/json' },
                    body: JSON.stringify({ hello: 'world' })
                })
            );
        return res;
    } catch (error) {
        console.log(error);
        return json('error');
    }
};

Create another endpoint, which will receive the request on the Container side.

routes/api/dev/container/+server.ts

import { json } from '@sveltejs/kit';

export const GET = async ({ request }) => {
    try {
        const body = await request.json();
        console.log(body);
        return json(body);
    } catch (error) {
        console.log(error);
        return json('error');
    }
};

Sending the Request

Start the server.

It appears to have started successfully.

For some reason, only the first request fails (possibly because it’s still in beta).

However, the Container itself is running.

So if you send the request again, it should succeed.

Since the request was successfully forwarded, try sending a POST request as well.

Thoughts

This time, I took an approach where the same application also runs inside a Container. Because Containers are not tied to a specific environment, that flexibility is very appealing. You can choose whatever runtime or environment you like, such as Node.js, Bun, or Deno.

Local development still requires several workarounds, but I expect this to improve over time. There is also still room to optimize the Dockerfile further, both in terms of build performance and image size.

I also use Cloud Run frequently. With Cloud Build, if you keep the region and machine specs unchanged, deployments can still take around five minutes even after aggressively shrinking the image. Cloudflare, on the other hand, seems to handle caching well—for example, skipping builds when there are no Worker-side changes—so deployments feel somewhat faster. With this Dockerfile, builds took roughly two minutes.

Why I Started Using Zed

qaynam — Fri, 13 Sep 2024 13:04:17 +0000

Why I Want to Become a Vimmer

I think every programmer has the dream of being able to use Vim smoothly (this might just be my personal belief). The reason Vim started to look so cool to me is because I began watching a YouTube channel called devaslife, where the person operates everything using just the keyboard, and I thought it was really cool.

In addition to him, there’s another tech influencer from the channel theprimeagen, and he also uses Vim like a pro, which I thought was really cool.

Moreover, there’s bawad, known among programmer geeks, and he is also a hardcore Vimmer. Watching him move the cursor so swiftly made me think it was really cool.

I feel like an elementary school kid admiring YouTubers, and I apologize for turning this into a YouTuber introduction corner 🙇‍♂️

Myself So Far

I started using VSCode in 2017, so I got used to operating with a mouse, and I couldn’t switch to Vim or Emacs right away. There are several reasons for that:

Vim doesn’t work just by installing it, like VSCode (well, it works, but not as an IDE).
You have to learn how to use it (obviously).
- I tried a Neovim tutorial at first, but if you don’t use it daily, you’ll forget it.
The extensions I frequently use in VSCode aren’t always available in Vim.
Choosing a terminal can be difficult.
- This might vary depending on personal preference, but there were times when the terminal didn’t get along well with Vim, causing display issues, which led to me giving up a few times.

Things I Tried to Become a Vimmer

Tried Installing the Vim Binding Plugin for VSCode

I gave up on this because there were times when I couldn’t input Japanese correctly, and there were many bugs, like not knowing which cursor mode I was in.

Tried Installing the VSCode Neovim Plugin

This extension seems to run based on the Vim installed on the machine, so it mostly works fine, but sometimes it conflicted with VSCode-specific shortcuts. Each time, I had to disable keys in the settings file, which was a hassle. VSCode also felt sluggish, and there were occasional bugs like the clipboard not being shared. The most critical issue was that some Neovim plugins were incompatible, and it ended up feeling like a half-baked mix of VSCode and Vim, leaving me frustrated.

Tried Installing AstroVim, Which is Kind of Like a Superset of Vim

Instead of installing Vim and configuring everything myself, this came pre-loaded with commonly used plugins, so it was really convenient. However, I couldn’t figure out how to use those plugins, and I got so frustrated that I gave up (I give up quickly 😪).

AstroNvim

An aesthetically pleasing and feature-rich neovim config that is extensible and easy to use with a great set of plugins

astronvim.com

Final Conclusion

Using the Zed Editor in Vim Mode

Zed - The editor for what's next

Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.

zed.dev

Why Zed?

Zed is an open-source editor written in Rust, developed by the creators of Atom (which has since been discontinued).
The shortcuts are similar to VSCode, so there aren’t many times when I get stuck because I don’t know the keys.
It runs very fast, and the startup time is overwhelmingly quick.
You can enable Vim mode without needing an extension.

However, since it’s still somewhat underdeveloped, it does feel a bit quirky, but not enough to be bothersome. The updates seem very frequent, so I believe it will get better eventually.

Using Vimium, a Chrome Extension

Chrome Web Store

chromewebstore.google.com

The purpose of this is to overcome the problem of forgetting Vim commands after doing the tutorials I mentioned earlier. Since I spend more time browsing than writing code, I figured that if I get used to cursor movements in the browser, moving the cursor in an editor won’t be as difficult (and it actually wasn’t). It’s also very easy to use.

However, the only problem for me was that I use the Arc browser for work, and there were slight differences in behavior from Chrome, like overlapping shortcuts or features, which made it a bit inconvenient at times, but it was manageable.

And that’s my journey to becoming a Vimmer.

use Redux with Svelte 👀

qaynam — Thu, 13 Jun 2024 10:28:04 +0000

I've been developing a product fully utilizing SvelteKit, and while server-side tests can be handled directly with Jest, unit testing on the client side can't be done just by adding Jest. Support for ESM needs to be added in various ways, it would be fine to break down logic into smaller functions for testing, but that makes the code a bit cumbersome to manage, and I also wanted to test changes in state, which was the start of it all.

Benefits I've considered by deciding on Redux:

Makes it easier to transition to a different framework in the future
- Less affected when updating from v4 to v5
Improves maintainability

Disadvantages I've considered:

Increases the amount of code
Requires various adjustments to operate in Svelte

Here is a rough code snippet like below👇

Store.redux.ts

import { configureStore, createSlice } from '@reduxjs/toolkit';

export interface MenuFormStore {
    name: string;
}

const initialState: MenuFormStore = {
    name: '',
};

const menuFormSlice = createSlice({
    name: 'menuForm',
    initialState,
    reducers: {
        setName: (state, action: { payload: string }) => {
            state.name = action.payload;
        }
    }
});

const MenuFormActions = menuFormSlice.actions;
const menuFormStoreRedux = configureStore({
    reducer: menuFormSlice.reducer
});
const MenuFormDispatch = menuFormStoreRedux.dispatch;

export const MenuFormReduxStoreModule = {
    initialState,
    Actions: MenuFormActions,
    Store: menuFormStoreRedux,
    Dispatch: MenuFormDispatch
} as const;

This file has nothing to do with Svelte, so you can write unit tests directly with Jest.
However, this alone does not make it reactive on Svelte, so we define a read-only store in a separate file using readonly from svelte/store like below (placing it in the same file will anger Jest)

Store.ts

import { onMount } from 'svelte';
import { writable, readonly } from 'svelte/store';
import { MenuFormReduxStoreModule } from './MenuForm.redux';

const state = writable(MenuFormReduxStoreModule.initialState);

export const getMenuFormStore = () => {
    onMount(() =>
        MenuFormReduxStoreModule.Store.subscribe(() => {
            state.update(prev => ({ ...prev, ...MenuFormReduxStoreModule.Store.getState() }));
        })
    );
    return readonly(state);
};

Usage within Svelte would be as below👇

Menu.svelte

<script lang="ts">
import { getMenuFormStore } from './Store';
import { MenuFormReduxStoreModule } from './Store.redux';

$: menuFormStore = getMenuFormStore();
const { Actions, Dispatch } = MenuFormReduxStoreModule;
</script>

<div>
{$menuFormStore.name}
<input on:input={e => Dispatch(Actions.setName(e.currentTarget.value))}/>
</div>

In Conclusion

Likely the same system could be used for jotai or zustand, which is appreciated since many issues are resolved in Svelte v5.

How to do SSR with SvelteKit and @emotion/css

qaynam — Sun, 14 Jan 2024 07:01:19 +0000

I’m developing a product using svelteKit and wanted to use css-in-js, so I adopted @emotion/css. Unlike React, there wasn’t much information on how to use it with Sveltekit, so I wanted to write down the method I found while reading the source code. If anyone knows a smarter way, please let me know🙇‍♂️

Flow

Use the extractCritical method from the @emotion/server package 👇 to generate static CSS and inject it into the head tag of the HTML response string generated from the server.

Implementation

In the case of React, you can use renderToString from react-dom/server to convert jsx to an HTML string, but the concept is quite different for Svelte, so the method is very different.

However, hooks are provided in the case of Sveltekit.

“Hooks” are app-wide functions you declare that SvelteKit will call in response to specific events, giving you fine-grained control over the framework’s behaviour.

It may be similar to entry.server.tsx in remix.

server.hooks.ts

import type { Handle } from '@sveltejs/kit';
import { extractCritical } from '@emotion/server';

export const handle: Handle = async ({ event, resolve }) => {
 const response = await resolve(event, {
  transformPageChunk({ html, done }) {
   const { html: emotionHtml, css, ids } = extractCritical(html);
   if (done) {
    return emotionHtml.replace(
     '</head>',
     `<style data-emotion-css="${ids.join(' ')}">${css}</style></head>`
    );
   }
  }
 });
 return response;
};

That’s it.

Trying Out Type Safe Navigation in SvelteKit

qaynam — Thu, 11 Jan 2024 13:25:28 +0000

Recently Switched from Next.js to SvelteKit and Loving It

Motivation

I wanted to implement tansack-router typing in Svelte like this👇

So I built my own and wanted to document it here.

Implementation

SvelteKit puts a lot of emphasis on type safety between server and client. When you start the dev server, it generates various types for data returned by load functions in .sveltekit/types.

You can import and use them from the $types alias like this 👇

https://kit.svelte.dev/docs/load#page-data

I thought I could do something similar with code generation. Looking through the SvelteKit source code, I found the create_manifest_data function




export default function create_manifest_data({
    config,
    fallback = `${runtime_directory}/components`,
    cwd = process.cwd()
}) {
    const assets = create_assets(config);
    const matchers = create_matchers(config, cwd);
    const { nodes, routes } = create_routes_and_nodes(cwd, config, fallback);

    for (const route of routes) {
        for (const param of route.params) {
            if (param.matcher && !matchers[param.matcher]) {
                throw new Error(`No matcher found for parameter '${param.matcher}' in route ${route.id}`);
            }
        }
    }

    return {
        assets,
        matchers,
        nodes,
        routes
    };
}

github link

I created a codegen.js file in the project root. It runs node codegen.js when starting dev server to continually watch for file changes.




import create_manifest_data from './node_modules/@sveltejs/kit/src/core/sync/create_manifest_data/index.js';
import { load_config } from './node_modules/@sveltejs/kit/src/core/config/index.js';
import fs from 'node:fs';
import { format } from 'prettier';

const specialRouteIdPattern = /(\/(\(|\[).*(\]|\)))?/g;

async function getRoutes() {
    /** @type import('@sveltejs/kit').ValidatedConfig */
    const config = await load_config();

    /** @type import("@sveltejs/kit").ManifestData */
    const manifest = await create_manifest_data({ config });
    return manifest.routes;
}

async function generateRouteTypeFile(
    /** @type import("@sveltejs/kit").RouteData[] */
    routes
) {
    const ids = routes
        .filter(
            (route) => Boolean(route.page))
        .map((route) => route.id.split('').join('').replace(specialRouteIdPattern, '')).filter(Boolean);
    const type = `export type RouteList = ${ids.map((id) => `"${id}"`).join(' | ')}`;

    fs.writeFileSync('./src/lib/type.d.ts', await format(type, { parser: 'typescript' }));

    return { routes: ids };
}

const { routes } = await generateRouteTypeFile(await getRoutes());
console.log('Routes:');
console.table(routes);
console.log('Generated route type file ✅');

console.log('Watching for changes...');
fs.watch('./src/routes', { recursive: true }, async (event, filename) => {
    console.log(`Change detected in ${filename} `);
    if (event === 'rename') {
        const routes = await getRoutes();
        await generateRouteTypeFile(routes);
        console.log('Generated route type file ✅');
    }
});

To briefly explain the code, we use a module that is not publicly available, get a route, exclude specific routes such as [.... .path] (gourp), generate the ts code, write it to the file, and keep waiting for the file to change.

When dev server starts, it generates src/lib/type.d.ts with route ids like:




export type RouteList = "/" | "/auth" | "/auth/forgot-password" | "/auth/reset-password" | "/auth/sign-in" | "/auth/sign-up"

Since SvelteKit has $app/navigation instead of react-router, I wrapped it in lib/navigation.ts file like this👇



import { goto } from '$app/navigation';

import type { RouteList } from '../routes/type';

export const navigate = (url: RouteList | URL, opt?: GotoParams[1]) => goto(url, opt);

Now I get type hints like:

Warning

This module is not exported from @sveltejs/kit, so it may stop working if destructive changes are made.