Remix is a full-stack, server-side web framework built on modern web standards and designed for fast, resilient, and highly interactive applications. Its core philosophy is to embrace the browser platform, using web APIs wherever possible, and to prioritize user experience through advanced routing, progressive enhancement, and optimized data loading patterns. Remix can only be used on Application Hosting; it cannot be deployed as a static site. We recommend the following best practices to get the best performance when using Remix on Sevalla:Documentation Index
Fetch the complete documentation index at: https://docs.sevalla.com/llms.txt
Use this file to discover all available pages before exploring further.
- Use Remix loaders for efficient, server-side data fetching.
- Apply appropriate
Cache-Controlheaders in loader responses to maximize CDN performance. - Take advantage of Remix’s built-in prefetching to speed up client-side navigation.
- Use resource routes for API endpoints to simplify data access and caching.
Containerization
Dockerfile
The build for Dockerfiles is fully customizable. The following is an example Dockerfile for Remix: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. You can influence the build process by adjusting thebuild script in your package.json. Buildpacks will run whatever command you specify under the build script. For example, the standard command used to compile a Remix application is:
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 Remix 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 Remix’s versioned assets in the
build/directory, which are safe to cache indefinitely. - Store static files in the
public/directory, allowing the CDN to serve them efficiently.
Image optimization
Static assets
Place static assets in thepublic/ 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 Remix 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 Remix’s
useFetcherfor 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 Remix 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 loaders
Loader caching with headers
Resource 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
Remix provides automatic graceful shutdown when usingremix-serve, but you can add custom cleanup logic, such as closing database connections, by handling SIGTERM 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 Remix 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 Remix 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.
Remix multi-tenant implementation
Extract tenant from subdomain in loader:Custom domains per tenant
Allow tenants to use their own domains (e.g.,customdomain.com → tenant data).
Map custom domains to tenants: