Functions
A function is a JavaScript or TypeScript file in a functions/ directory at the root of your project. It exports a handler that takes a Web API Request and returns a Response, the same shape Netlify, Cloudflare and Deno use, so a handler written for one of them usually runs here unchanged. Your next production deploy bundles each file on its own and registers it under the file’s name. There is no framework to add, no configuration file and no separate build step.
Every function has two doors, and the same file answers both.
Call it over HTTPS. Each function gets its own hostname, https://{name}-{subdomain}.fn.deploybase.eu, with a certificate already in place. A request to that hostname runs your handler and returns whatever Response it produced, so a page on your site can fetch() it directly. Instances scale to zero when nobody is calling. The first request after a quiet spell takes 2 to 5 seconds while an instance starts; the requests after it do not.
Queue it through the API. A POST to https://api.deploybase.eu/api/v1/public/functions/{subdomain}/{name} answers 202 Accepted at once with a URL to poll. The function runs in the background in its own container, and the poll URL returns its status code, headers and body when it has finished. This suits work that does not need to answer inside the request: a webhook that can take a while, a job you fire from a script. The reference describes the request and reply shapes.
Getting started takes you from an empty functions/ directory to a live URL. The reference holds the contract, the limits and the errors.
Getting access
Section titled “Getting access”HTTP functions are in closed beta. A team owner or admin applies from the billing page, or from app.deploybase.eu/functions-beta, and accepts the beta terms on the team’s behalf. We review applications by hand and email you when the team is in. Access is per team, so every project on the team gets it at once, and it applies whatever plan the team is on, including Free.
Functions cost nothing during the closed beta. When it ends they become part of paid plans at published pricing, with at least 30 days notice by email before anything changes. The terms on the application page say exactly what that means; this page does not repeat them.
Queued calls are not gated by the beta. Any team can queue a function today; only the HTTPS hostname needs the grant.
Where your code runs
Section titled “Where your code runs”- Compute: Scaleway Kapsule in Paris, on nodes reserved for functions. Every instance runs under gVisor, a sandbox that keeps one customer’s code away from the host kernel and from other customers, on top of the usual container isolation.
- Bundles: stored in a private Bunny.net storage zone in Germany. Nothing under
functions/is ever published to your site’s CDN. - Logs and queued-call records: Paris. Request bodies and results of queued calls are kept for 7 days.
- Outbound network: functions can reach the public internet over HTTPS only. Plain HTTP, private networks and the cloud metadata service are blocked.
Our DPA covers personal data your functions process.
Not there yet
Section titled “Not there yet”These are on the list, none with a date. Watch the changelog.
- Environment variables for functions. Project variables reach builds only, and
context.envis empty of anything you set. - Scheduled functions.
- Framework adapters, so a SvelteKit or Astro server build can deploy as a function. Today a handler is a file you write.
- Warm instances. Every function scales to zero, and the cold start above applies.
- Logs for HTTPS calls in the dashboard. Queued calls show their output; HTTPS calls do not yet.
- Usage metering and per-plan request caps. The beta asks for fair use instead.
- A path on your own domain routed to a function. A function is reachable at its own hostname only.
Something broke, or something here is wrong? Send feedback from the app, or write to support@deploybase.eu.