Changelog

ES decorators are enabled on Deno Deploy, replacing experimental TS decorators

TL;DR

Deno Deploy throws an error at build time if the code being deployed uses decorators and the experimentalDecorators flag is not explicitly set in the compiler options. To resolve this error, specify your preferred flavor of decorators in the deno.json file as follows:

{
  ...
  "compilerOptions": {
    // true:  enable TypeScript decorators
    // false: enable ECMAScript decorators
    "experimentalDecorators": true
  }
}

Background

As we announced in the Deno 1.39.0 and 1.40.0 blog posts, Deno now enables ECMAScript Decorators by default, as standardized by TC39, replacing the experimental TypeScript decorators that were previously enabled by default. You can still configure which flavor to use in compilerOptions in deno.json.

This update has been applied to Deno Deploy as well, but with some challenges in the transition process. The most impactful change that may require users’ action is that code that was deployed and executed successfully before the change might fail either at build time or runtime if it is redeployed now without any change. This issue could happen if the following two conditions are met:

• the code uses TypeScript decorators, and
• the experimentalDecorators flag is not set to true

This is because the build process on Deno Deploy now transpiles the decorators as ECMAScript decorators, while it used to as TypeScript decorators. Note that in general these two decorators are not compatible with each other.

To ensure a controlled transition Deno Deploy will give an error at build time if the code being deployed uses any kinds of decorators and the experimentalDecorators flag is not explicitly set to any value. This is to ask users to explicitly specify their preferred decorator flavor in order to avoid any unexpected behaviors that may occur due to the difference between the two decorators.

deployctl 1.9.0: token provisioning, config file, and much more!

With the 1.9.0 release of deployctl, manual access-token handling is a thing of the past! 🎉 Starting with this release, if a token is not provided via arg or env, a new one will be provisioned using an OAuth authorization flow.

Additionally, several other improvements have been introduced to simplify the user experience of the tool: this version introduces support for a config file where some settings like project, entrypoint, include and exclude can be configured and shared. This config file is created at the end of a deployment if it does not exist yet. It defaults to deno.json (integrating with the rest of deno CLI configuration), and looks like this:

{
  ...
  "deploy": {
    "project": "6067570b-ee11-4e2e-b7df-692d11e049d5",
    "exclude": [],
    "include": [
      "main.ts",
      "deps.ts"
    ],
    "entrypoint": "main.ts"
  }
}

You can continue to perform deployments using the --entrypoint and --project flags (which now will create the project automatically during deployment if it does not exist). However, we have introduced some heuristics to try and make deployments even more simple. Now deployctl guesses the project name of the deployment based on the Git repository it is in (or directory name if the deployment is not performed within a repository). Similarly, it guesses the entrypoint by looking for files with common entrypoint names (main.ts, src/main.ts, etc), so that, most of the time, having your code deployed around the globe can be as simple as running:

deployctl deploy

Automatic deployment validation on Deno Deploy

Starting today, Deno Deploy will perform automatic validation of new deployments. A new deployment will first be pushed into an ephemeral V8 isolate for a quick smoke test. If the isolate fails, the deployment will not be published and you will be able to see the validation errors in the deployments dashboard.

The validation is meant to catch errors that would otherwise only be discovered at runtime (e.g. calling a function that does not exist).

Currently, validation is performed in soft-fail mode, meaning that the deployment will still be created even if the validation fails. We plan to monitor this over the next few weeks and then switch to hard-fail mode.

KV key expiration support on Deno Deploy

The key expiration feature of Deno KV is now supported on Deno Deploy.

You can use the expireIn parameter on kv.set() or kv.atomic().set() to set the expiration time of a key:

// expires in 86400 seconds (1 day)
await kv.set(["sessions", session.id], session, { expireIn: 86400 * 1000 });

GitHub app permissions and new project templates

Today, the Deno Deploy team rolled out changes to the new project workflow to better support some of your favorite web frameworks, like Astro, SvelteKit, Nuxt, and more. To do this effectively, we needed additional permissions for our GitHub app to access workflows for your projects.

Many web frameworks designed in the Node.js ecosystem require a build step prior to deployment. With access to GitHub workflows, Deno Deploy can automate the configuration of those build steps for you.

For existing Deploy users, you may be prompted to give Deno’s GitHub app additional permissions if you’d like to take advantage of these new project features.

If you have any questions or feedback, don’t hesitate to reach out to us at deploy@deno.com.

NPM specifiers support on Deno Deploy

NPM specifiers are now supported on Deno Deploy for all users. You can now import NPM modules directly from within your Deno Deploy projects, without the need for a build step.

Here’s an example of running an Express app on Deno Deploy:

// Import express and instantiate it
import express from "npm:express@4";
const app = express();

// Register a route
app.get("/", (req, res) => {
  res.send("Hello World!");
});

// Run the server!
app.listen(3000);

View the blog post for more details →

Deno KV is in open beta

Deno KV, the easiest way to add a strongly consistent database to your application, is now in open beta. You can get free access to Deno KV by simply signing up for Deno Deploy.

View the blog post for more details →

Connect to Deno KV from outside Deno Deploy

Now you can use global Deno KV from AWS Lambda, GCP, Fly.io, locally, and more by creating a Deno Deploy personal access token and setting it as an environmental variable DENO_KV_ACCESS_TOKEN, then passing your database URL to Deno.openKv():

const kv = await Deno.openKv(
  "https://api.deno.com/databases/<database-id>/connect",
);

You can find your database ID, URL, and more information on how to connect to your managed KV database from your Deno Deploy project page:

This makes it easier to handle data imports, migrations, and more.

Learn more about connecting to your global Deno KV →

More Deno KV read regions for lower latency

By default, every Deno KV database comes with a single write region and a single read region. If your users are all over the world, some may experience longer latencies due to the single read region.

Now, enable more read regions to expand your database globally for even lower latency:

Increased Deno KV atomic operations

Atomic operations allow you to perform multiple operations in a single transaction. If any of the operations fail, the entire transaction is rolled back, ensuring that your data is always consistent.

Previously, you could only perform up to 10 mutation operations in a single transaction. This limit has been increased to 1,000 mutations per atomic operation or a total atomic operation size of 800 KiB, whichever is reached first.

Introducing Deno KV pricing

We’re excited to announce transparent Deno KV pricing that scales with your needs. Deno KV is billed along three dimensions:

• storage: amount of data you store in your database per month
• read units: each time you read from the database, in 4 KiB units
• write units: each time you write to the database, multiplied by the number of enabled regions, in 1 KiB units

Here is the complete pricing table for more details:

As a reminder, using Deno KV locally without Deno Deploy will be free.

Read the announcement blog post or check out our pricing plans →

deployctl 1.8.0: query and filter logs

With deployctl 1.8.0, you can query and filter logs from the command line with deployctl logs. It supports both live logs where the logs are streamed to the console as they are generated, and query persisted logs, where it fetches logs generated in the past.

Here are some examples:

To show the live logs of a project's latest deployment:
  deployctl logs --project=helloworld

To show the live logs of a particular deployment:
  deployctl logs --project=helloworld --deployment=1234567890ab

To show the live error & info level logs of the production deployment generated in particular regions:
  deployctl logs --project=helloworld --prod --levels=error,info --regions=region1,region2

To show the logs generated within the past two hours, up until 30 minutes ago, and containing the word "foo":
  [Linux]
  deployctl logs --project=helloworld --since=$(date -Iseconds --date='2 hours ago') --until=$(date -Iseconds --date='30 minutes ago') --grep=foo
  [macOS]
  deployctl logs --project=helloworld --since=$(date -Iseconds -v-2H) --until=$(date -Iseconds -v-30M) --grep=foo

For the full list of options:

    --deployment=<DEPLOYMENT_ID>  The id of the deployment you want to get the logs (defaults to latest deployment)
    --prod                        Select the production deployment
-p, --project=NAME                The project you want to get the logs
    --token=TOKEN                 The API token to use (defaults to DENO_DEPLOY_TOKEN env var)
    --since=<DATETIME>            The start time of the logs you want to get. RFC3339 format (e.g. 2023-07-17T06:10:38+09:00) is supported.
                                  NOTE: Logs generated over 24 hours ago are not available
    --until=<DATETIME>            The end time of the logs you want to get. RFC3339 format (e.g. 2023-07-17T06:10:38+09:00) is supported.
    --grep=<WORD>                 Filter logs by a word
                                  Multiple words can be specified for AND search. For example, "--grep=foo --grep=bar" will match logs containing both "foo" and "bar"
    --levels=<LEVELS>             Filter logs by log levels (defaults to all log levels)
                                  Mutliple levels can be specified, e.g. --levels=info,error
    --regions=<REGIONS>           Filter logs by regions (defaults to all regions)
                                  Multiple regions can be specified, e.g. --regions=region1,region2
    --limit=<LIMIT>               Limit the number of logs to return (defualts to 100)
                                  This flag is effective only when --since and/or --until is specified

Persistent Logs

Searchable and filterable logs are key to testing, debugging, and iterating fast.

Now, you can view your application logs within the past 24 hours and filter them based on time, level, and region.

Multi-line environment variables

Deno Deploy now supports environment variables with content spanning over multiple lines.

This means that you can now add more structured environment variables, such as certificates, through the settings page of your project.

Automatically Detecting Frameworks

You may be surprised to learn that Deno Deploy doesn’t just serve Deno apps globally at the edge with minimal latency. In fact, many choose Deno Deploy to serve their Remix, Svelte, Astro (and more) apps close to their users.

We’ve made it easier to connect and deploy these frameworks by automatically detecting them when you connect a new GitHub repo.

An example of Deno Deploy detecting a Remix app and recommending a deployment method which uses a build step.

These frameworks will be automatically detected:

• Next.js with SSG
• Remix
• Astro
• Docusaurus
• Gatsby
• Svelte
• Vite
• React (create-react-app)
• Nuxt
• Solid
• Storybook
• Angular
• Qwik

We’re working on supporting more. If you have a framework you’d like us to detect, please let us know.

Fast, easy, global web servers with Deno.serve()

Before, building a web server required importing std/http and several lines of code. Now, you can now start a performant web server that’s deployed globally for sub-100ms latency in a single line:

Deno.serve((req) => new Response("Hello world"));

Read more about how easy it is to use Deno.serve() in the 1.35 blog post.

Statically analyzable dynamic imports

Deno Deploy now supports statically analyzable dynamic imports. This means that you can use import() in your code and the module will be fetched at build time to be included in eszip (a format to bundle deployment code) generated by Deno Deploy. The code will be loaded and executed at runtime only when it is needed for the request.

In the below example, the uuid module will be fetched at build time to be included in the eszip, but it will be loaded & executed at runtime when the script serves the request.

import { serve } from "https://deno.land/std@0.192.0/http/server.ts";

serve(async (req: Request) => {
  const { version } = await import("https://deno.land/std@0.192.0/uuid/mod.ts");
  const ver = version("109156be-c4fb-41ea-b1b4-efe1671c5836");
  return new Response(ver);
});

Dynamic imports that are not statically analyzable don’t work. For example, the below code will throw a module not found error at runtime because the module specifier changes based on the value Date.now(), so the code is not included in the eszip.

import { serve } from "https://deno.land/std@0.192.0/http/server.ts";

serve(async (req: Request) => {
  const mod = `./module_${Date.now()}.ts`;
  const { hello } = await import(mod);
  return new Response(hello);
});

deployctl 1.7.0

deployctl, the CLI tool for Deno Deploy, has been updated to 1.7.0.

Starting with this release, deployctl deploy is now able to detect whether it is trying to push the very first deployment to a new empty project. In that case it will now take care of initializing the production environment and pushing the initial deployment to it.

This only affects the first push to an empty project. The default behavior for subsequent deployments has not been changed, and still requires the --prod flag for further updates to the production environment.

Read more in the full changelog.

New project creation flow

The new project creation flow has gotten a makeover. It is now be much easier to get started with templates like a simple Fresh project.

Built-in Node modules support

Deno Deploy now supports importing built-in Node modules like fs and path using node: specifiers. This makes it easier to port existing Node.js code to run on Deno Deploy.

The node:http module is also supported, making it possible to run web servers originally written for Node natively on Deno Deploy. For example, here is a simple HTTP server written using node:http, that serves the current time and the region that served the request:

import { createServer } from "node:http";
import process from "node:process";

const server = createServer((req, res) => {
  const message = `Hello from ${process.env.DENO_REGION} at ${new Date()}`;
  res.end(message);
});

server.listen(8080);

You can see it live here: https://dash.deno.com/playground/node-specifiers

The full list of supported Node built-in modules is available in the documentation.

deployctl 1.6.0

deployctl, the CLI tool for Deno Deploy, has been updated to 1.6.0. This version has a compatibility fix related to deployctl logs subcommand.

For those who are not familiar with deployctl logs, it’s a subcommand to stream logs from Deno Deploy, which was introduced in 1.5.0 (thanks @rolitoxdd for implementing it). With deployctl logs you don’t have to open a browser and go to the dashboard - everything is done in the terminal.

Improvements

Other improvements include:

• Switched to Deno.Command
• Updated log response types of log streaming endpoint

Read more in the full changelog.

Added more Deno.* APIs

Our goal is to maintain parity between Deno CLI and the Deno runtime in Deno Deploy.

Here’s the full list of Deno namespace APIs added to Deno Deploy:

• Deno.version
• Deno.ChildProcess
• Deno.Command
• Deno.consoleSize
• Deno.gid
• Deno.uid
• Deno.hostname
• Deno.loadavg
• Deno.memoryUsage
• Deno.networkInterfaces
• Deno.osRelease
• Deno.osUptime
• Deno.systemMemoryInfo
• Deno.refTimer
• Deno.unrefTimer

deployctl 1.5

We’ve made incremental improvements in this minor release of deployctl, the CLI tool for deploying projects to Deno Deploy.

Improvements

• Bumped dependencies
• Added deno.lock
• Added deployctl logs subcommand

Read more in the full changelog.

New data center: 🇮🇱 Tel Aviv

We’re excited to announce we’ve increased our global data centers to 35 with the addition of Tel Aviv.

View all of our supported regions.

Auto-discover deno.json(c) from deployctl deployments

Currently, configuration file deno.json(c) is only auto-discovered when the deployment is performed via GitHub Automatic mode.

Now, when deploying via GitHub Actions or deployctl, Deno Deploy will auto-discover deno.json(c).

Support for Deno.readLink

We’ve added support for Deno.readLink, which allows getting the link target for symlinks.

deployctl 1.3

We’ve made incremental improvements in this minor release of deployctl, the CLI tool for deploying projects to Deno Deploy.

Improvements

• Improved error logging with trace id
• Upgraded std version
• Removed makefile
• Added --dry-run option

Read more in the full changelog.

New data center: 🇺🇸 Texas

We’re excited to announce we’ve increased our global data centers to 34 with the addition of us-south1.

View all of our supported regions.

Automated Wildcard SSL certification provisioning

Provisioning SSL certifications with custom domains can be a hassle, so we’ve added support for automated wildcard SSL certification provisioning. Now, once you’ve added your custom domain to your Deno Deploy project, you can provision SSL certification with a single click.

Add environmental variables when linking a GitHub project

We aim to make deploying to Deno Deploy as simple as possible, so now you can define your environmental variables in the same step as linking your GitHub project.

New data center: 🇺🇸 Ohio

We’re excited to announce we’ve increased our global data centers to 33 with the addition of us-east5.

View all of our supported regions.

Deno Deploy Beta 4

Today we are releasing Deno Deploy Beta 4, bringing the service a step closer to General Availability. In this release we improve the dashboard, add billing functionality, add 3 new regions, and improve analytics

Everyday more and more infrastructure is being built on top of Deno Deploy – services like Netlify Edge Functions and Supabase Edge Functions build on Deno Deploy Subhosting. We encourage you to give it a try even tho it is still in beta!

Improvements

• Added pricing. Currently we offer Free plan and Pro plan.
• Added 3 new regions: Milan, Madrid, and Paris.
• We’ve vastly improved the Deno Deploy dashboard to make it easier to manage apps.

Learn more in the blog post.

deployctl 1.2

We’ve made incremental improvements in this minor release of deployctl, the CLI tool for deploying projects to Deno Deploy.

Improvements

• Improved logging
• Added support for import maps

Read more in the full changelog.

deployctl 1.0

We’re excited to announce the 1.0 release of deployctl, the CLI tool for deploying projects to Deno Deploy.

The biggest update with the 1.0 release is the addition of the deployctl GitHub Action, which is a simple way to add a build step to your Deno project when deploying to Deno Deploy.

Learn more about using deployctl as a GitHub Action.

Deno Deploy Beta 3

Today we are releasing Deploy Beta 3. This is the third in a series of beta releases that will be made over the coming months. Each release will add features and refine the programming model. The releases will culminate in a General Availability announcement that we estimate will happen in Q4 2021.

Over the past year, we have been quietly designing this hosted service to supplement workflows with the open source Deno CLI. Deploy does not run on AWS Lambda nor does it use Cloudflare Workers; this is a new system with a unique design. We encourage people to look past the rough initial UI and explore this new JavaScript runtime.

Deploy’s goal is to be the best place to host modern server-side JavaScript.

Improvements

• The below New APIs are added.
  • Outbound TCP and TLS connections are supported now.
  • DNS resolution: Deno.resolveDns()
  • Added URLPattern API
• Playground has been added. You can quickly test your deployment with online editor in browsers.
• Organization feature has been added. You can manage the projects with your team members.

Learn more in the blog post.

Deno Deploy Beta 2

Today we are releasing Deploy Beta 2. This is the second in a series of beta releases that will be made over the coming months. Each release will add features and refine the programming model.

Over the past eight months, we have been quietly designing this hosted service to supplement workflows with the open source Deno CLI. Deploy does not run on AWS Lambda nor does it use Cloudflare Workers; this is a new system with a unique design. We encourage people to look past the rough initial UI and explore this new JavaScript runtime.

Deploy’s goal is to be the best place to host modern server-side JavaScript.

Improvements

• Static files can be loaded using Deno.readFile.
• Deno.listen and Deno.serveHttp have been added.
• Crash report page has been added.
• Dashboard has the new design.

Learn more in the blog post.

Deno Deploy Beta 1

Today we are releasing Deploy Beta 1. This is the first in a series of beta releases that will be made over the coming months. Each release will add features and refine the programming model.

Over the past eight months, we have been quietly designing this hosted service to supplement workflows with the open source Deno CLI. Deploy does not run on AWS Lambda nor does it use Cloudflare Workers; this is a new system with a unique design. We encourage people to look past the rough initial UI and explore this new JavaScript runtime.

Deploy’s goal is to be the best place to host modern server-side JavaScript.

Improvements

• Fast deployments.
• TypeScript, JSX, ES Modules, HTTPS imports are supported.
• BroadcastChannel is supported.
• Custom certificates are supported.
• Fresh framework is available.

Learn more in the blog post.