Solutions

Stackap for conventional web apps

An ordinary web app, a front end, an API, a Postgres database, uploaded files and a few scheduled jobs, maps almost one to one onto what Stackap provides.

The situation

Most web apps are not exotic, and a platform built for the common shape can do it well. The test is a short list: front end, API, database, files, scheduled work, a domain. If your app is those six things and nothing else, this page is for you.

If it also needs a queue, a worker with no web port, a search engine or a second database, the map has holes.

What Stackap gives you here

• Front end: a Next.js app, a single-page app or a static site, built from your repository.
• API: a Node app with a start script, or your own Dockerfile.
• Database: one private Postgres per project, with a table browser.
• Files: storage in your own R2 bucket.
• Scheduled work: cron calls to a path on your app, in UTC.
• Domain: your hostname with automatic HTTPS.

How it looks in practice

The front end and the API can be one Next.js project or two projects. Two is cleaner if the API is used by more than the front end, and it lets each scale and deploy on its own. Each gets a hostname, and the front end calls the API at its absolute address.

Put secrets only in environment variables, keep public values to the prefixed ones, write cron endpoints so that calling them twice is harmless, and take a backup and restore it into a scratch database once, before you need it.

Early-access fit

Early access is a less natural fit if your app depends on a queue or on workers that run without a web port. Neither is supported today.

Early access is a less natural fit if you need regions close to users on several continents. There is one server.

Early-access scope

• No queue, no background workers, no second database engine.
• One server in Germany.
• No previews, so review changes on a staging project.
• Recovery is from daily backups with no point-in-time option.

Questions

Last updated 2026-10-03.