By ByteBot
The Svelte team shipped SvelteKit 3’s Release Candidate on August 13, 2026, and buried the most interesting line deep in their own announcement. Remote functions, they wrote, “make everything else look a bit clunky, including SvelteKit’s load functions and actions.” It is a remarkable thing for a framework to say about its own core API — and a reliable signal that this SvelteKit 3 RC release matters more than a typical major bump.
Remote Functions: The Actual Story
Remote functions let you call server-side code directly from a Svelte component. No +server.ts file. No fetch wrapper. No manually synced TypeScript types. You write a function in a .remote.ts file, import it in your component, and call it. SvelteKit compiles a typed HTTP endpoint behind the scenes and your component has no idea there is a network involved.
There are four function types. query handles data reads. form handles progressively enhanced form submissions. command handles JavaScript-dependent mutations. prerender computes static data at build time. Each maps cleanly to a use case that previously required a combination of load functions, form actions, and hand-rolled API routes. The official remote functions documentation covers each type in detail.
// src/lib/server/posts.remote.ts
export const getPosts = query(async () => {
return db.posts.findMany();
});
// src/routes/+page.svelte
<script>
import { getPosts } from '$lib/server/posts.remote';
const posts = await getPosts();
</script>The performance angle is real: SvelteKit executes mutations as single-flight requests — mutation plus query refresh in one round trip, no stale data. Compare that to Next.js Server Actions, which were designed primarily for writes and leave you managing cache invalidation yourself.
The comparison to tRPC is just as sharp. tRPC requires a router, an adapter, and a typed client before you can call a single server function. SvelteKit remote functions require an import. The end result — full type safety from database to component — is identical. The setup is not.
Breaking Changes You Actually Have to Deal With
svelte.config.js is gone. Kit configuration now lives inside vite.config.js, passed directly to the sveltekit() Vite plugin. This is the most visibly disruptive change for existing projects, but it is also the right call — Vite was already the center of gravity, and a single config file is easier to reason about than two.
// vite.config.js — SvelteKit 3
import { sveltekit } from '@sveltejs/kit/vite';
export default defineConfig({
plugins: [sveltekit({ /* your kit config here */ })]
});SvelteKit 3 also raises its minimum dependencies: Node.js v22.17, TypeScript v6, Svelte v5.56.4, and Vite v8. Vite 8 ships the Rolldown bundler, which means faster production builds. The Node minimum will block any team running on an old CI image — check yours now.
The Environment Variable Model Finally Makes Sense
Explicit environment variables — previously behind an experimental flag — are now the default. You declare which variables your app needs in src/env.ts, mark them public or private, and specify whether they resolve at build time or runtime. The old $env/static/private and $env/dynamic/public split disappears. What you get is an auditable list of every external value your app depends on, in one file.
How to Migrate
One command handles most of the breaking changes automatically:
npx sv@next migrate sveltekit-3 --tasks all --confirmThe recommended path: upgrade to the most recent SvelteKit 2.x release first. That version surfaces targeted deprecation warnings that make the migration script more precise. Then run the command. Review the diff. Ship it. The official SvelteKit 3 migration guide covers edge cases the script cannot handle automatically.
Additional improvements in SvelteKit 3 include shallow routing baked directly into goto, module-based service workers, a new $app/manifest module, and tracing graduated out of the experimental namespace.
Should You Migrate Now?
This is an RC, which means stable is close and the Svelte team is explicitly asking developers to try it and report issues. The migration tooling is solid. The remote functions are still experimental in the RC — they will graduate to stable when 3.0 ships. If you are building something new, start with SvelteKit 3 today. If you are maintaining an existing SvelteKit 2 project, run the migration on a branch, verify your build and tests pass, and merge when you are confident.
The underlying message from the Svelte team is harder to ignore: when the people who built load functions say remote functions make them look clunky, the architecture just improved. That is worth paying attention to.
