You can now configure an external OpenTelemetry collector to export
observability data from your Deno Deploy organization.
Set a custom OTLP endpoint and headers from the organization settings page
under "OpenTelemetry".
All traces, metrics, and logs from your applications will be forwarded to
your configured collector in addition to being available in the Deno Deploy
dashboard.
The runtime memory limit for applications can now be configured per app.
Available memory limits range from 512 MB to 4096 MB, depending on your
plan.
The memory limit can be set in the app build configuration settings, or via
the deploy.runtime.memory_limit field in your deno.json file.
A new Builder plan is now available for organizations that need higher limits
and more compute.
The Builder plan is priced at $200/month and includes 20 million included
HTTP requests, 400 CPU hours, up to 4 GB runtime and build memory, and up to
200 deployments per hour.
Deno Deploy apps can now be configured through deno.json / deno.jsonc
files in addition to the dashboard settings.
All app configuration options available in the dashboard are also available
in the deno.json file under the deploy section. This includes install
and build command, runtime configuration, and framework presets.
When both dashboard and deno.json configuration are present, the
deno.json configuration takes precedence and overrides the app
configuration in the dashboard entirely.
This makes it easier to manage app configuration as code, and keep it in
version control alongside your application code.
Deno Deploy can now detect Deno and NPM workspace / monorepo configurations,
allowing you to deploy applications located in subdirectories of a larger
repository.
During app creation, we'll now scan the repository for workspace
configurations, and allow you to select which workspace member to deploy.
During builds, the working directory is set to the workspace member's
directory.
The app directory can be customized after app creation in the app config
settings.
The build logs now have a dedicated "Deploy" section that replaces the
previous "Warmup" and "Routing" steps, providing more clarity on what is
happening during deployment.
Inside of the "Deploy" section, you'll find sub-sections for each timeline
that the revision is being deployed to, including production, git branches,
and preview deployments.
The "Warmup" sub-section shows logs related to prewarming the application.
The "Pre-deploy" sub-section shows logs related to running the user-defined
pre-deploy command, for example to run migrations.
The "Database creation" sub-section shows logs related to creating any
linked databases for the timeline.
The top navigation bar has been redesigned to include a breadcrumb dropdown
for the current section of the dashboard. This allows you to quickly navigate
between, for example, apps and domains.
You can now skip deploying a specific commit using the GitHub integration by
including the string [skip ci] or [skip deploy] in the commit message.
Revisions that have not received traffic for more than 30 days are now
automatically disabled, and deleting after a further 7 days of inactivity.
Disabled revisions can be re-enabled before deletion from the revisions
page.
The deno deploy CLI and --tunnel flag for deno run and deno task now
support using organization tokens for authentication, in addition to user
tokens.
To use an organization token, pass it as usual in the DENO_DEPLOY_TOKEN
environment variable.
We have rolled out several runtime security patches to address recently
disclosed vulnerabilities in React and Next.js:
CVE-2025-55182 (Remote
Code Execution) and
CVE-2025-55184/CVE-2025-67779 (Denial
of Service).
And one more thing at the end: we've quietly enabled our new Deno Sandbox
infrastructure for all Deno Deploy users to try.
Deno Sandbox provides fully isolated Linux microVMs for you to run untrusted
code in.
This is particularly useful for running third-party code, such as plugins,
extensions, or user-generated or LLM-generated code, without risking the
security of your application.
We'll announce more details about Deno Sandbox in the new year, so stay
tuned!
Try it out from the "Sandboxes" tab in the Deno Deploy console
Fixed an issue where some Next.js and Astro builds would fail when installing
dependencies with a frozen lockfile.
Fixed an issue the _acme-challenge CNAME DNS records was displayed without a
trailing dot, causing confusion when copying the record value for DNS
verification.
Deno Deploy can now securely expose locally running applications on a public
domain using the deno run --tunnel / deno task --tunnel.
This is particularly useful for testing webhooks from third-party services,
or sharing work-in-progress applications with colleagues or clients.
The tunnel creates a secure connection from your local machine to Deno
Deploy's infrastructure, and provisions a temporary public domain that
routes traffic to your local application.
In addition, --tunnel automatically pulls down "Local" environment
variables from the Deno Deploy dashboard, making configuration and secrets
management much easier.
Open Telemetry metrics, logs, and traces are also collected from local
applications and can be viewed in the Deno Deploy dashboard, the same way as
deployed applications.
Postgres databases can now be directly provisioned from the Deno Deploy
dashboard, hosted by our friends at Prisma.
Like other externally linked databases, each timeline (production, git
branches, and previews) in every app, gets its own isolated database schema
and data.
You can manage your database directly from the Deno Deploy dashboard, with
options to export your database to your own Prisma account for further
management.
Customizable build timeouts (defaulting to 5 minutes, up to 15 minutes on
Pro plan)
Customizable memory allocation for the builder (defaulting to 3GB, up to 4GB
on Pro plan)
The directory that builds run in can now be customized, enabling deployment
of applications inside of a monorepo
Applications can now set the runtime working directory that is used when
booting up the application after a successful build
Users can now sign in to Deno Deploy using Google, in addition to GitHub.
From the account settings page, you can link both Google and GitHub to your
account, allowing you to sign in with either provider.
The playgrounds list on the organization overview page has been merged into
the apps list, allowing you to see and manage all your deployed code from a
single place.
Playgrounds now have an overview page, similar to apps, showing metrics,
builds, logs, and traces.
Playgrounds can now be assigned custom domains through the settings.
The domain and database dropdowns in the assignment drawers now support
searching, making it easier to find the domain or database you want to assign
when you have many.
Billing and metering has moved to a new dedicated page per organization,
showing detailed usage breakdowns, invoice history, and payment methods, plan
details, and more.
Applications now have a dedicated databases page, showing all linked
databases, their status, and options to manage them.
The .env import field in the environment variable drawer is now more visible,
and now supports drag-and-drop of .env files
Fixed a bug where the percentage in usage alert emails was off by 100x (e.g.
showing 100% instead of 1%). This was caused by a decimal vs percentage mixup.
The package managers npm, yarn, and pnpm now more reliably install
dependencies during the build step.
The environment variable value input field now handles multiline values
correctly, and does not strip out newlines anymore.
Fix some organizations not being unsuspended immediately after verifying with
a credit card.
Fix some builds hanging when a user provided install or build command does not
terminate quickly on SIGTERM.
Changing the slug of a database instance now correctly updates the slug in the
URL bar, ensuring that the page can be refreshed without error.
Build timeouts are now displayed as timeouts, rather than generic
cancellations, in the build logs, and build history.
A timeline does not have to be unlocked anymore before being able to be locked
to a new revision, if already locked to a revision.
Metering and billing is now enabled for all organizations on Deno Deploy.
After creation, all organizations default to the Free plan, which includes
generous free usage limits each month. To learn more about the Free and Pro
plans, see the pricing page.
Free organizations that exceed their usage on requests, bandwidth, or CPU or
memory time will have their applications paused until the next billing
cycle, while Pro organizations will be billed for the overage at the end of
the month.
Organizations can only make use of restricted Free plan limits until they
verify their organization by linking a credit card.
The Pro plan enables features such as wildcard custom domains, priority
support, and increased included limits.
Spend limits are available to Pro organizations, allowing you to cap your
monthly spend to avoid unexpected charges.
Deno Deploy now supports issuing OIDC tokens for all applications at runtime,
allowing you to securely authenticate to third-party services and APIs without
needing to manage long-lived static credentials.
When authenticating to AWS or GCP, you can make use of the Cloud Connections
feature instead, which will guide you through set up and automatically
handle token retrieval and rotation for you.
Learn more about Cloud Connections.
In addition to TLS certificates provisioned automatically through Let's
Encrypt by Deno Deploy, you can now upload and manage custom TLS certificates
for your domains. This is useful for organizations that use EV or OV
certificates, or have specific compliance requirements.
If a certificate nears expiration, we'll send email reminders to the
organization owners to renew the certificate.
This feature is only available to organizations on the Pro plan.
Applications that are linked to GitHub repositories now dispatch GitHub
repository_dispatch events every time a build is started, or completed
(successfully or failed). These events can be picked up by GitHub Actions
workflows to trigger additional actions, such as notifying a Slack channel, or
running additional tests.
See the documentation for more details.
Domains can now be unassigned from an application through the organization
domains page, without needing to go to the application settings.
When bulk importing environment variables, the heuristic to detect whether a
variable is a secret or plain text has been improved. Now, variables with keys
containing PUBLIC_ are always treated as plain text.
Some metrics on the organization and app metrics pages were displaying second
values as milliseconds, causing them to appear 1000x too low. This has been
fixed.
Deno KV can now be used with the database integration:
Provision a Deno KV database through the "Databases" tab, and link it to an
app or playground.
Access the Deno KV database from your code by using Deno.openKv().
KV queues, read-replication, manual backups, and choosing a primary region
are not available at this time.
Playgrounds now support dragging in individual files and folders.
The playground file explorer now supports inline rename and delete of files.
New built-in environment variables have been added to enable detection of Deno
Deploy EA, and the app that is running, and the organization it is running in:
DENO_DEPLOY=1, DENO_DEPLOY_ORG_ID, DENO_DEPLOY_ORG_SLUG,
DENO_DEPLOY_APP_ID, DENO_DEPLOY_APP_SLUG, DENO_DEPLOY_REVISION_ID.
Users can now create personal access tokens from their account page.
Check that Postgres database instances support dynamic provisioning of
databases before allowing them to be linked to an organization.
Ensure that deleted Deno Deploy apps will never trigger GitHub status checks
on push to the previously linked repo.
The playground HTTP explorer now correctly sends the set headers when making
requests.
Playgrounds do not error on top level await anymore.
You can now add environment variables named GOOGLE_APPLICATION_CREDENTIALS
to your Deno Deploy app.
When bulk importing environment variables in the app settings, we now
correctly import them into that app, rather than mistakenly importing them
into the organization environment variables.
Some versions of Next.js, that do not support using declarations, now
correctly build again.
npm install in the build step now works more reliably, and does not fail
with certificate related issues anymore.
New: Database support for Deno Deploy apps, allowing you to easily connect to
and use Postgres databases in your applications.
Provision a Postgres database instance on AWS RDS, Neon, Supabase, or any
other provider and then link it to your Deno Deploy organization.
Assign the database instance to an application, making it available in the
application's environment.
Every timeline (production, each git branch, and previews) has their own
isolated database with a separate schema and data, allowing you to test
migrations and changes without affecting production data.
Use any Postgres client library to connect, including npm:pg,
npm:drizzle, or npm:kysely.
Applications and playgrounds can now be renamed. Note, old deno.net URLs
will no longer work after renaming, but custom domains will continue to
function.
Applications and playgrounds can now be deleted.
Playgrounds now have an HTTP Explorer tab that allows you to make arbitrary
HTTP requests to any URL served by the playground. This is useful for testing
APIs or other services that do not serve a web page.
You can now delete entire folders in the playground file explorer by pressing
the delete button next to the folder name.
You can now drag a zip file onto the playground file explorer to upload all
files in the zip file to the playground.
You can now enable auto-format on save in the playground, which will
automatically format your code when you save a file.
New: Cloud Connect allows you to securely connect your Deno Deploy apps to AWS
and GCP, enabling you to use services like AWS S3, Google Cloud Storage,
without needing to manage credentials.
This is done without storing any long-lived static credentials, but rather
using short-lived tokens and OIDC (OpenID Connect) to establish a trust
relationship between Deno Deploy and your cloud provider.
A setup flow in the app settings page, or a drawer in playgrounds, guides
you through the process of connecting your app to AWS or GCP.
You can use the standard AWS and GCP SDKs to access the services - no need
to re-write any code to use a different API.
The application metrics page now shows more metrics, including V8 memory
metrics such as heap size and garbage collection stats, as well as process
level metrics such as CPU usage and overall memory usage.
There is now a new "Metrics" tab in the organization overview that shows
overall metrics for all applications in the organization, including the number
of requests, CPU usage, and memory usage.
You can now edit the URL you are viewing in the playground preview iframe by
editing the "address bar" that is displayed above the preview.
Environment variables now default to being a secret when the key contains
SECRET, KEY, TOKEN, PRIVATE, or PASSWORD. You can still manually
switch them to plain text if needed.
The maximum length limit for environment variable values has been increased to
4096 characters, up from 1024 characters.
Playgrounds do not get stuck when attempting to deploy an empty file anymore.
Playground drawer resizing now works more reliably, especially when some
drawers are collapsed.
Builds now take significantly less time to complete, especially for larger
projects. The "Warmup" and "Routing" steps, which previously took more than 10
seconds respectively, now usually take less than 1 second each.
Builds can now be cancelled while they are in the "Queueing" and "Routing"
steps.
The organization creation page now correctly displays whether an organization
slug is taken or not, prior to submitting the form.
npm install can now install esbuild again - previously it would fail with
a generic error.