Backend apps

A backend without the servers under it

Deploy services as functions in Node, Python or Ruby. They scale with traffic, run in eight regions, and share one database.

Start building
services
volcano cloud functions deploy --allcheckout      nodejs22    deployedinvoicing     python3.12  deployednotifications ruby3.4     deployedvolcano cloud functions logs checkout --type runtime --followPOST /checkout  201  84ms  user 8f1c…✓ scaled to zero between requests
Overview

Most of a backend is not your product

A service needs a container image, a registry, a scheduler, health checks, autoscaling rules and a load balancer before it handles a single request. That machinery has to be maintained by someone, and none of it is the thing you set out to build.

On Volcano a service is a function. Deploy the directory and Volcano handles placement, scaling and TLS across eight regions, with a Postgres database beside it that your services reach over the ordinary wire protocol.

Runtimes

Pick the language per service

Node, Python and Ruby all run as first-class functions, so a service can sit wherever its libraries already are. Nothing forces one language across the whole backend.

  • Node.js 22 and 24, handler index.handler
  • Python 3.10 to 3.14, handler main.handler
  • Ruby 3.3, 3.4 and 4.0
volcano cloud functions runtimes
nodejs22    nodejs24python3.10  python3.11  python3.12python3.13  python3.14ruby3.3     ruby3.4     ruby4.0# one backend, three languages, no extra infrastructure
Placement

Close to whoever called

One hostname resolves to the nearest of eight production regions, so a request from Sydney is not answered from Virginia. There is no region routing for you to configure.

  • Eight regions across four continents
  • One hostname, answered from the closest region
  • No load balancer to run
us-westOregon, USA
us-eastN. Virginia, USA
eu-westDublin, Ireland
eu-centralFrankfurt, Germany
sa-eastSão Paulo, Brazil
ap-northeastTokyo, Japan
ap-southeastSingapore
ap-southeast-2Sydney, Australia
CoverageNearFar
Eight production regions, reached through one endpoint.
Operations

Nothing to provision, nothing to size

There is no instance to pick, no autoscaling group to tune and no pooler to keep alive. Memory and timeout are the same for every function in the project, so a new endpoint is a file and a deploy rather than a capacity decision.

  • No always-on instance to right-size
  • Placement and scaling handled for you
  • A new endpoint is a file, not a capacity plan
volcano cloud functions deploy --all
orders     nodejs24.x   deployed to 8 regionsinvoices   python3.12   deployed to 8 regionswebhooks   ruby3.4      deployed to 8 regions# no instance to choose, no pooler to keep alive✓ 3/3 deployed · scaling handled for you
Path to production

How it works

  1. 01

    Split by service

    One function per service. Each gets its own runtime, logs and deploy.

  2. 02

    Share one database

    Migrations live with the code, and every service connects with the same string.

  3. 03

    Keep secrets out

    Project variables are injected at runtime and deployed with the rest of the config.

  4. 04

    Deploy and watch

    Ship everything with one command, then follow build or runtime logs per service.

Code

A service, its data, its config, its deploy

JavaScript
const { Client } = require('pg'); const { databaseConnectionString } = require('@volcano.dev/sdk'); exports.handler = async (event) => { const auth = event.__volcano_auth; if (!auth) { return { statusCode: 401, body: JSON.stringify({ error: 'sign in required' }) }; } const { cartId } = event; // Connect as the caller so the cart policy applies here too. const db = new Client({ connectionString: databaseConnectionString(process.env.DATABASE_URL, { userId: auth.user_id, }), }); await db.connect(); try { const { rows } = await db.query( 'select id, total_cents from carts where id = $1 and checked_out_at is null', [cartId], ); if (rows.length === 0) { return { statusCode: 404, body: JSON.stringify({ error: 'cart not found' }) }; } await db.query('update carts set checked_out_at = now() where id = $1', [cartId]); return { statusCode: 201, body: JSON.stringify({ orderTotal: rows[0].total_cents }) }; } finally { await db.end(); } };
Return

What disappears

0servers to operate

No cluster, no images, no autoscaling rules, no pooler in front of the database.

8 regionswith no routing to write

One hostname resolves to the closest region automatically.

3 languagesin one backend

Node, Python and Ruby side by side, each service using whichever fits.

What you get

Nothing to operate

No cluster, no images, no autoscaling rules to tune.

Independent services

Each one deploys, logs and fails on its own.

Scaling you do not tune

Traffic goes up, Volcano runs more copies. No rules to write.

Platform

Built on Volcano

Functions and agents

  • The services

    Functions in Node, Python or Ruby, deployed per service, with build and runtime logs kept separate.

Databases and vector

  • Shared state

    PostgreSQL 15 or 16 reachable over the wire protocol, from your services and from psql alike.

Authentication

  • Callers

    Sessions verified before your handler runs, arriving on the event as a real user.

File storage

  • Files and artifacts

    Buckets for uploads, exports and generated documents, with policy-based access.

Frequently asked questions

Read the docs
How long can a request take?

Up to 180 seconds per invocation. The ceiling applies to every function in the project rather than being configured per function, and the figure for each plan is on the pricing page.

Can different services use different languages?

Yes. The runtime comes from each function's entrypoint file, so a Node checkout service and a Python invoicing service live in the same project and share the same database.

How do services talk to each other?

Over HTTP, or through the SDK with volcano.functions.invoke. Marking an internal service private makes it refuse the anon key, so a browser carrying only that key is turned away while your own calls still get through.

Where do secrets live?

In project variables, declared in volcano-config.yaml with values interpolated from the environment and injected at runtime. Nothing sensitive is committed.

What about a long-running worker?

There is no always-on process. Use a scheduled function that claims a batch of work each run, which also survives restarts better than a daemon holding state in memory.

How do I debug a failing deploy?

volcano cloud functions logs <name> --type build shows what happened during packaging, and --type runtime --follow streams live invocations once it is deployed.

Ready to deploy your backend?

Build, deploy, and scale on Volcano's global platform — free to start, with no infrastructure to manage.

Start building free

Explore more solutions

Multi-tenant SaaS← Multi-tenant SaaSBuilding APIsBuilding APIs →