Deno is a modern, secure runtime for JavaScript and TypeScript. It is built with Rust and emphasizes security by requiring explicit permissions for file, network, or environment access. Deno supports TypeScript natively, includes a standard library, and utilizes URL-based module imports instead of a centralized package manager, providing a streamlined and secure alternative for server-side development and scripting. Deno can only be used on Application Hosting; it cannot be deployed as a static site.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.
Configuration
Deno runs TypeScript directly, eliminating the need for a separate build or installation step. With Sevalla:- Dependencies are cached automatically on the first build.
- Your app can be started using
deno task startor any custom start command you configure.
deno.json file:
--allow-net- Enables network access (required for HTTP servers).--allow-env- Access to environment variables.--allow-read- File system read access (if needed).--allow-write- File system write access (if needed).
Containerization
Dockerfile
The build for Dockerfiles is fully customizable. The following is an example Dockerfile for Deno:Nixpacks
Nixpacks automatically detects Deno projects by looking for:deno.jsonordeno.jsoncin the project root.- Deno imports in TypeScript files.
deps.tsfile (common Deno convention).
- Install the latest Deno runtime.
- Cache dependencies from remote imports.
- Execute your start command as defined in
deno.json.
deno.json with a start task, as follows:
deno task start to start your application.
Custom configuration with nixpacks.toml
You can customize the Nixpacks build process by defining a nixpacks.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:
Common Nixpacks configurations
Basic Deno applicationCDN
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 Deno application, we recommend the following best practices:- Enable the CDN for all production applications.
- Set appropriate
Cache-Controlheaders on API routes to ensure proper caching behavior. - Purge the CDN cache after deploying critical updates to avoid serving stale content.
- Use versioned URLs for static assets, for example
/static/app.v123.js.
Optimizing Deno for CDN
Static files with cache headers
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 Deno 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.
Optimizing Deno for edge caching
Cache-Control
With Sevalla’s Cloudflare integration, Cache-Control headers 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 Deno 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.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.
Basic health check
Graceful shutdown
Deno supports graceful shutdown signals. For custom cleanup logic, such as closing database connections, useSIGTERM and SIGINT, for example:
S3
You can integrate your Deno application with S3 (Sevalla S3, AWS S3, or any S3-compatible storage) using the AWS SDK or JavaScript v3.Setup
- Install dependencies (auto-cached on first run):
- Configure environment variables: