Functions overview

A function is a Node.js or Python handler that runs on each HTTPS request.

Functions suit webhook receivers, small APIs, scheduled jobs, and glue code between services. For something that runs continuously, such as a web server or a background worker, use an app or VPS.

• Runtimes: Node.js 22 and Python 3.12, or your own Dockerfile.
• Deploys: from the browser editor, a GitHub folder, or the synteq CLI.
• Address: an HTTPS subdomain on fn.synteq.app, plus custom domains.
• Scaling: instances start on the first request and stop after an idle period.
• Cron triggers: run the function on a UTC schedule.
• Billing: per run, and on some plans per GB-second.
• Monthly budget: an optional cap on runs per month.

Functions live inside a project. Creating or changing a function needs the Technical role, owner, or admin. Read-only members can view functions, logs, and usage.

Every function gets its own HTTPS address as soon as it's created:

https://<name>.fn.synteq.app

The name becomes the subdomain, so it uses lowercase letters, numbers, and hyphens, up to 63 characters. It can't start or end with a hyphen, and it must be unique across Synteq. Custom domains are added from the Domains tab.

When a request arrives and no instance is running, Synteq starts one. The request waits while it boots; this is a cold start. Node.js and Python handlers start from a pool of runtimes that is already booted, so a cold start is the time to load your handler. In most cases, declared dependencies are part of that pool and add nothing. Typical cold starts, measured inside the Dallas datacenter:

A handler that loads a large native module (an image library, for example) adds that module's load time to its cold start. A running instance adds 10–20 ms of platform overhead per request inside the datacenter. It stops after 90 seconds without requests, and the next request starts a new one.

Traffic that arrives in bursts with long gaps pays a cold start at the start of each burst.

Each instance serves up to Concurrency requests at once, 10 by default. When every instance is busy, Synteq starts another, up to Max instances, 5 by default.

At the defaults a function serves 50 requests at once. Requests beyond that wait for a free slot rather than fail, so latency rises. Raise Max instances if this happens regularly. Requests also queue while instances start, and a very large burst can get a 503.

Handlers that mostly wait on I/O work well at a Concurrency of 10 or more. For CPU-bound handlers, lower it so requests spread across more instances.

Each instance is a separate microVM with its own kernel, memory, and filesystem. Nothing is shared with other customers or with your function's other instances.

Instances start and stop as traffic changes, and consecutive requests can land on different instances. Keep state in a database or other external store, not in memory or on local disk.

A request runs for up to 30 seconds by default. The Timeout in Settings goes up to 5 minutes. A request that exceeds it returns 504 and is logged as timed out.

An uncaught error in your handler returns 500, and the error appears in the run's logs. If no instance is ready within 30 seconds, the request returns 504; it never reached your code and isn't billed.

The dot next to the status reflects most runs over the last 30 minutes, or the latest run when there were none in that window: green for success, red for an error or timeout.

The runtime size sets each instance's memory. CPU scales with memory. The size also sets the maximums for Concurrency, Timeout, and Max instances. Some plans fix the size.

A run is one request that reaches your handler, whatever the result. Successes, errors, and timeouts each count as one run, as do cron runs and runs started with Trigger now.

Requests that never reach your handler are not runs: the 429 from a paused function and the 504 when no instance is ready in time.

Some plans also bill compute in GB-seconds: instance running time multiplied by memory in GB. One 512 MB instance running for a minute uses 30 GB-seconds.

Compute is measured for as long as an instance runs, including the 90 seconds before an idle instance stops, not per request.

Plans are chosen on the Billing tab. Your organization's catalog can include:

Every plan, including Free, needs a payment method on the organization. Usage resets monthly on the day the function was created.

Some organizations use a shared credit pool instead of per-function plans. The Functions list then shows a team credits balance, and functions have no Billing tab of their own.

The plan either fixes what happens when included runs run out, or lets you choose under Settings → Spend:

The Billing tab shows which applies. Changing plan clears the choice.

Monthly budget under Settings → Spend caps runs per month. At the cap the function pauses and your team is notified. Leave it empty for no cap.

A paused function returns 429. Deploys still work and go live on resume. The banner shows why when the pause came from your budget or plan:

To delete a function, pause it first. Deleting becomes available after 14 days paused.

Functions appear under their project in the sidebar, in the Cloud section. The list shows each function's name and address, its latest deploy with when and by whom, its runs over the last 30 days, and its health.

The synteq function commands in the CLI cover the same operations.

• Writing and deploying a function: the handler format and the three ways to deploy.
• Triggers, operations, and billing: cron, logs, rollback, custom domains, and the Billing tab.
• Getting started with the CLI: install, log in, and deploy from a terminal.