- Use SvelteKit
loadfunctions for efficient server-side data fetching. - Add appropriate
Cache-Controlheaders to pages and server route responses. - Enable SvelteKit’s prefetching and preloading to enhance client navigation speed.
- Implement APIs using server routes (
+server.ts) for better control and performance. - Ensure compression is enabled in your server configuration.
- Use streaming with async
loadfunctions to deliver content progressively and reduce TTFB.
Configuration
To configure your SvelteKit application for Sevalla, you must ensure@sveltejs/adapter-node is properly configured in svelte.config.js .
The following is an example svelte.config.js file for deploying SvelteKit on Sevalla:
Containerization
Dockerfile
The build for Dockerfiles is fully customizable. The following is an example Dockerfile for SvelteKit:Nixpacks
You can customize the Nixpacks build process by defining anixpacks.toml file and using Nixpacks-specific environment variables. This allows you to fine-tune how dependencies are installed, how your application is built, and which runtime settings are applied.
The following is an example nixpacks.toml configuration:
NIXPACKS_NODE_VERSIONenvironment variable.
Buildpacks
If you’re using Buildpacks, you cannot modify the underlying build phases directly or control dependencies. You must rely on the runtime environment that Buildpacks detects. Ensure yourpackage.json has the correct scripts for the buildpack deployment:
buildscript: Compiles your SvelteKit application.startscript: Runs the production server (buildpack uses this).
@sveltejs/adapter-node is configured in svelte.config.js:
CDN
Sevalla provides a premium, Cloudflare-powered CDN for Application Hosting at no additional cost. To get the most out of Sevalla’s CDN when deploying your SvelteKit application, we recommend the following best practices:- Enable the CDN for all production applications to ensure global, low-latency delivery.
- Set appropriate
Cache-Controlheaders on API routes to ensure proper caching behavior. - Purge CDN cache after critical deployments to ensure users receive updated content.
- Rely on SvelteKit’s versioned assets in the
.svelte-kit/output/directory, which are safe to cache indefinitely. - Store static files in the
static/directory, allowing the CDN to serve them efficiently.
Image Optimization
Static Assets
Place static assets in thestatic/ directory:
Edge caching
Edge caching stores your Sevalla site cache on Cloudflare’s 260+ global data centers, delivering responses from the location nearest to each visitor for faster performance. To maximize the benefits of Sevalla’s Edge Caching for your SvelteKit application, we recommend the following best practices:- Set appropriate
Cache-Controlheaders in loaders to control caching behavior. - Combine edge caching with the CDN for a complete caching strategy.
- Use SvelteKit’s
invalidateAllorinvalidatefor client-side revalidation.
Cache-Control
With Sevalla’s Cloudflare integration,Cache-Controlheaders are respected at the edge, giving you precise control over how content is cached and served globally. The following are some common directives you can use in your SvelteKit application:
public, s-maxage=3600- Caches the response on the CDN for 1 hour, improving performance for frequently accessed content.public, max-age=31536000, immutable- Ideal for versioned static assets, allowing them to be cached for up to 1 year with no revalidation.private- Prevents CDN caching and ensures the response is only cached by the end user’s browser, for personalized or sensitive data.
Sevalla does not yet support the
stale-while-revalidate Cache-Control directive. To prevent unexpected caching behavior, we recommend not using this directive in your API or asset caching settings.Cache-Control headers for server routes
Page load function caching with headers
Server routes with caching
Client-side revalidation
Health checks
Ensure your application remains available during deployments by implementing health checks:- Always implement health checks for production applications.
- Keep checks lightweight; responses should complete in under 1 second.
- Verify critical dependencies (e.g., databases, Redis) as part of the checks.
- Return 200 for degraded states to allow deployments to continue smoothly.
- Return 503 only for critical failures that require pod restarts.
- Close connections cleanly (e.g., database pools, Redis) to prevent resource leaks.
- Test deployments in staging with monitoring scripts to validate health checks.
Basic health check
Graceful shutdown
SvelteKit with adapter-node provides automatic graceful shutdown, but you can add custom cleanup logic, such as closing database connections, by handlingSIGTERM and SIGINT yourself. The example below demonstrates how to shut down a PostgreSQL connection pool during termination:
Multi-tenancy
Sevalla fully supports multi-tenancy. You can build multi-tenant SvelteKit applications using wildcard domains, allowing you to efficiently and securely serve multiple tenants from separate subdomains. Use the following best practices for multi-tenancy on Sevalla with your SvelteKit application:- Use wildcard domains to serve subdomain-based tenants (e.g.,
tenant1.app.com). - Add custom domains individually for tenants who have their own domains.
- Cache tenant data to reduce database queries and improve performance.
- Validate tenant existence before rendering pages to prevent errors or unauthorized access.
- Isolate tenant data in the database using separate schemas or a
tenant_idcolumn. - Leverage free SSL certificates, which are automatically provided for both wildcard and custom domains.
SvelteKit multi-tenant implementation
Extract tenant from subdomain in load function:Custom domains per tenant
Allow tenants to use their own domains (e.g.,customdomain.com → tenant data).
Map custom domains to tenants: