Stackap Cloud

Stackap is your own GitHub, Vercel and Supabase in one box. You push your code to it with git push. Within about two minutes it has built the code in a container, checked that the new version is healthy, switched your domain over to it, and kept the previous version one command away.

Around that push it does everything else a small company needs a stack of subscriptions for. It hosts the git repositories. It issues and renews HTTPS certificates. It gives each app its own private Postgres database. It stores uploaded files. It runs scheduled jobs. It takes encrypted backups to a bucket you own, and it proves those backups restore. It watches itself and sends you a message when something needs attention.

And it is multi-tenant. One Stackap can host many organizations, each walled off from the others, so the same box that runs your own products can run the products of your clients, your team, or your customers.

Hosting is where it starts. A small business also runs on a phone line, an inbox and a set of books, and the plan is to bring those into the same place: a phone service and an email service next, then financial services. All of it is built to be operated by the same agent, from one account. The roadmap has the order.

What has been measured

• About 96 seconds to build the first real application, a 31,592-page Next.js website, on the server.
• 24,988 database rows and 93 files copied from the old stack to the new one with zero mismatches, checked table by table and file by file.
• 43 of 43 deliberate cross-tenant attacks refused by the walls between organizations.
• About 700 requests per second from one four-core server on real pages, with no errors.

Early access

Stackap is a new platform that has not launched publicly. A limited number of teams are being invited, with hands-on onboarding, so the product can be shaped by people running real applications on it. If you run several applications and want one place to deploy, operate and back them up, ask for an invitation.

The rest of this page explains what Stackap is, why it exists, how it works, what is inside it, how it keeps tenants apart, and how the first move went.

Open the account page of any modern small software company and you will find the same three or four subscriptions. One service holds the code. A second builds that code and puts it on the internet. A third provides the database, the user accounts and the file storage. Usually a fourth sends the emails and a fifth watches for errors. Each is excellent at its job. Each has its own dashboard, its own login, its own pricing page, its own limits, and its own way of surprising you on the first of the month.

Stackap collapses that stack into a single program running on a single machine that you own. It is not a collection of scripts. It is one control plane, with one database, one API, one command-line tool and one dashboard, which manages everything your applications need in order to run.

What you actually do with it

The day-to-day experience is deliberately boring. You create a project. You get a git address. You push to it.

# once: create the project and point your repo at it
stackap create my-app --name "My App"
git remote add stackap git@your-box:my-app.git

# every time: this is the entire deploy
git push stackap main

# remote: build queued → image built → health check passed → live
# something wrong? one command puts the last version back
stackap rollback my-app

That is the interface. Everything else on this page is what happens behind it, and what you get for free because it happens in one place.

The parts, in one table

Here is how the hosted services you may be paying for map onto what Stackap does itself. The right-hand column is not a promise of feature parity with the giants; it is a statement of what exists and works today.

What it is not

Stackap is not a cloud. It does not have data centers, an edge network or an army of engineers on call. It is software that turns one ordinary server into a very capable application platform. The server comes from a hosting company; the bucket comes from Cloudflare; the intelligence is the part that is ours. That distinction matters, because it tells you exactly what Stackap is responsible for and what you choose: the machine, its location and its size are yours.

Modern web development asks you to assemble an application platform out of other people's products. That works, and it has a price that does not appear as a line item. Call it the stack tax: what you pay, in money, time and attention, for the work of keeping several products pointed at each other. It has four parts.

1. The bill, which grows with your success

Hosted platforms price by usage, and usage is the one thing a growing product cannot control. Build minutes, function invocations, bandwidth, database size, storage, seats, preview environments, log retention: each is a meter, and each meter has a free tier that ends at a different moment. The bill is not high because anyone was careless. It is high because the pricing model is designed to track your success. A server has a price instead of a meter, which makes next year's bill something you can read today.

2. The glue, which is yours to maintain

Three platforms do not know about each other. Your code lives in one, your builds in another, your data in a third. The seams between them are your responsibility: webhooks registered in the right place, environment variables copied between dashboards, secrets that exist in three vaults, a deploy that succeeded in one system and silently did nothing in another. During the work behind this page, one deployment stopped following pushes five separate times, and the cause on the fifth was almost comic: the continuous-integration service had used up its monthly budget, so checks never started, so the deploy platform waited forever for checks that were never going to report. Two services were each correctly doing their job, and the combination was an outage.

3. The lock-in, which you notice only when you leave

Every managed feature is also a hook. A proprietary database client, a platform-specific cron format, a storage API that exists in exactly one place: each saves a day of work and costs a week of migration later. Stackap is built from parts you can take with you: standard Postgres, containers, git, and files in a bucket you own.

4. The attention, which is the scarcest cost of all

The part that rarely makes it into a spreadsheet is the number of places you have to look. Which dashboard has the error? Which one has the bill? Which login does this contractor need? A single place to look is the difference between a ten-minute fix and a lost afternoon.

Stackap exists because its founder runs several businesses on software he writes himself: a classifieds site for New York City, a cleaning company's booking system, and a multi-tenant CRM that serves dozens of other businesses. Hosting them meant living across several vendors, and the question was whether that was still the best way to run them.

The realization

The hard part of running your own platform was never the server. It was the software around the server: the deploy pipeline, the certificate renewal, the database provisioning, the backups you have actually tested, the monitoring that actually tells someone, the isolation between customers. Writing, testing and hardening all of that used to be a team's work for a year. It is the reason hosted platforms exist.

AI coding assistants changed the cost of that work. Not to zero, and not without judgment: every wall in Stackap was designed by a human who knew what he wanted, and every claim in it is backed by a test written to fail if the claim were false. But the typing, the research, the cross-checking against documentation, the writing of hundreds of tests, now takes days instead of quarters.

When building the platform becomes this much cheaper, it is worth asking again whether you should rent it.

The principles it is built on

• Nothing is finished until a check that could have failed has passed. Every feature described on this page was exercised against a real system, not just compiled.
• Never touch production without a yes. The first application was copied onto Stackap as a staging site while the live one kept serving, and the switch was one DNS edit, approved by a human, at a moment he chose.
• Prefer proven software to clever software. Postgres, Caddy, Docker, PostgREST, the official Supabase storage service, Cloudflare R2. Stackap's own code is the glue and the guard rails, not a reinvention of the engine.
• Make failure visible. A scheduled job that never ran says so. A backup that was never restored is never called verified. A deploy that fails its health check never goes live.
• Copy walls that already work. The tenant isolation is modeled on the system that already keeps a hundred customers' data apart in the founder's CRM, down to the style of test that attacks it.

The goal

The first goal is concrete: every product the founder owns, on one box he controls. The second is the reason the multi-tenant work exists. If one box can host his products, it can host other people's: a small agency, a studio with a dozen client sites, a team of freelancers sharing infrastructure. That is a second use for the same software, and it is why the walls between organizations are built the way they are.

The most useful way to understand Stackap is to follow one push all the way through. Nothing in this section is simplified for effect; it is the actual sequence, in the actual order.

Step 1: the push

Your laptop talks to a dedicated, deliberately restricted user on the box over SSH. That user cannot open a shell, cannot run arbitrary commands, and cannot see anything except git repositories. The forced command behind it accepts exactly two operations, sending and receiving a repository, and rejects everything else. A repository name that is not allowed looks exactly like one that does not exist, so a key can learn nothing about what it is not permitted to touch.

Step 2: the hook

When the push lands, a hook inside the repository tells the control plane over a localhost-only, secret-protected endpoint. The control plane records the push and queues a build. Only pushes to the project's production branch queue a build; other branches are stored and ignored.

Step 3: the build

The build runs inside Docker on the same machine. If your repository contains a Dockerfile, Stackap uses it. If it does not and the project is a Next.js application, Stackap generates one. The build is careful about secrets: public build-time values are passed through, everything else is replaced with harmless placeholders, and the final image starts from a clean base so no build-time scaffolding leaks into what runs in production. Real secrets exist only at runtime.

Step 4: the health check

The new container starts alongside the old one, not instead of it. Stackap polls it until it answers successfully or until a timeout expires. A container that crashes on start, hangs, or returns an error is marked unhealthy and discarded. At no point during this has a visitor been sent to it.

Step 5: the swap

Only after the health check passes does Stackap change the routing table, inside a database transaction, so that the change either happens completely or not at all. Caddy begins sending traffic to the new container. The previous version is kept running as a rollback target. If anything in the swap fails, including the call to the proxy, routing is left exactly as it was.

Step 6: rollback, if you want it

One command re-activates the previous deployment, health-checking it first. Rollback is not a special mode with special risks; it is the same swap, pointed backwards.

Domains and HTTPS

You attach a domain to a project and Stackap tells you the one DNS record to create. Routing for that domain stays off until the record is correct, and certificates are obtained automatically only after that. The reason is practical: a certificate request against a domain that does not point at the server yet fails noisily and can trip rate limits. Making DNS the gate removes a whole class of confusing half-working states.

One real-world detail is worth sharing, because it is the kind of thing that only appears when you do this for real. When the first production domain was switched over, its DNS record had a time-to-live of twenty-four hours. Some visitors kept reaching the old host for hours after the change. The lesson is old and unglamorous: lower the TTL a day before any cutover. It is now in the migration checklist.

This is the feature tour. For each piece, we say what it does and, where it matters, how we know it works. If a capability is thin, we say that too.

Git hosting

Every project gets a bare git repository on the box and a git address to push to. Access is over SSH through a single restricted user whose forced command allows only sending and receiving repositories. Repository names are validated strictly, and every organization's keys are limited to that organization's repositories.

Build

Docker builds on the box, using your Dockerfile or a generated one for Next.js. Build-time secrets never reach the running image. A typical large Next.js build, the 31,592-page classifieds site, took about 96 seconds and produced a 164 MB image.

Deploy and rollback

A new version starts beside the old one, must pass a health check, and only then receives traffic through a transactional routing swap. One live deployment per project; the previous one is retained, and one command restores it.

Domains and HTTPS

Caddy terminates TLS with automatic certificates. Routing for a custom domain stays off until its DNS points at the box, and the certificate is requested only after that.

Environment variables

Encrypted at rest with AES-256-GCM under a master key, bound to the project and the variable name so a value cannot be swapped between them. Never shown back in plain text; the dashboard and CLI display masks. Injected only when a container starts.

Databases

Each project can have its own Postgres database and its own login role. The role can connect to its own database and no other; connection rights on the system databases are revoked. This was tested by attempting cross-database connections with two real roles. The connection string is stored encrypted and injected at runtime.

Data API

PostgREST sits in front of a project's database, so an application written for the Supabase JavaScript client can keep working unchanged. It was tested with the real client against the query shapes a large production codebase uses: filters, joins, upserts, counts, and database functions. Row-level security policies are honored, and the row cap matches Supabase's default of 1,000.

File storage

The official Supabase storage service, writing objects to a Cloudflare R2 bucket you own. Uploads, public URLs, listing, deletion and signed upload URLs all work with the standard client. The storage metadata lives in the project's own database, so a database backup also captures it.

Scheduled jobs

A built-in scheduler on UTC time. It runs each job once per fire time, never lets runs of the same job overlap, and records a visible "missed" run if the scheduler itself was down. A vercel.json cron block can be imported as it stands. Jobs call your own application on localhost with a bearer secret, so a job cannot be pointed at an outside address.

Logs

Build logs and a live runtime tail from the running container, from the CLI or the dashboard.

Dashboard and CLI

A static dashboard served under a strict content-security policy, and a command-line tool covering login, projects, deploy, rollback, logs, environment variables, domains, crons and status.

Migrator

A tool that copies a Supabase project's schema and data into a Stackap project. It is read-only against the source by construction: it refuses to send anything other than a SELECT. It then verifies row counts table by table.

Backups, in detail

Backups are where hosted platforms most often over-promise and where self-hosting most often under-delivers, so this part is built with extra care.

• Consistent. The dump is taken from a single exported database snapshot, and the table row counts are recorded from the same snapshot, so the manifest describes the dump exactly, even while the application is writing.
• Encrypted. Every backup is encrypted with AES-256-GCM before it leaves the server. The key is derived from the master key, and the object's name is authenticated into the ciphertext, so a backup cannot be renamed or swapped without detection.
• Off the box. Backups go to a Cloudflare R2 bucket. If the server vanishes, the backups do not.
• Restore-tested. A restore only ever goes into a brand-new database, never over a live one. Verification restores the latest backup into a temporary database, compares every table's row count with the manifest, and only an exact match marks the backup verified. The temporary database is always dropped.
• On a schedule. The loop checks hourly: a backup for any database without a good one in the last day, a verification weekly, and pruning daily, always keeping the newest three backups.
• Code too. Every git repository, including Stackap's own source, is bundled, encrypted and uploaded the same way, and restore-verified weekly.

Monitoring, in detail

Ten checks run continuously: CPU load, memory, disk, Postgres, running containers, database backups, repository backups, certificates, deployments, and scheduled jobs. Alerts fire on transitions only. You get one message when something starts failing, a reminder every six hours while it stays broken, and a recovery message when it clears, delivered to Telegram and written to the service log. The point is signal: an alert system that cries wolf is an alert system that gets muted.

A platform that hosts only its owner's projects is a tool. A platform that can safely host several independent parties is a business. Stackap is built to be the second, and the difference lives entirely in one question: if two organizations share this machine, how sure are you that neither can see or touch the other?

The model

Every project, access token and git key belongs to exactly one organization. The operator's own work lives in a special platform organization. Everyone else gets their own, created by the operator, with an owner token that is shown once. Three roles exist:

Platform admin

The operator. Creates and disables organizations, sees host-wide health and alerts. Exists only in the platform organization.

Owner

Runs an organization: creates projects, manages tokens and git keys, and works on everything inside the organization.

Member

Works on the organization's projects. Cannot mint or revoke tokens or manage keys.

The same walls that already work

The founder's CRM serves roughly a hundred separate businesses from one codebase and one database, and its tenant isolation has been hardened through security audits and a growing suite of attack tests. Stackap copies that approach rather than inventing a new one, layer for layer:

1. A single wall module. Every lookup of a project, and every lookup of anything reached by an identifier, such as a build, a backup, a token or a key, goes through one module that filters on the caller's organization. The organization comes from the access token and from nowhere else. A different organization in a request body, a header or a query string changes nothing.
2. Uniform not-found. A resource in another organization and a resource that does not exist produce byte-for-byte identical responses. An attacker cannot even learn that a project name is taken by someone else's project.
3. A static audit that fails the build. A test reads every route's source and fails if any query touches projects, tokens, keys, builds or backups without an organization filter. The audit logic is itself tested with deliberately leaky examples, including the subtle one where a query merely selects the organization column without filtering on it. A short, reasoned allow-list covers the one internal endpoint that is not tenant-facing, and a test fails if an allow-list entry goes stale.
4. An attack suite. Forty-three tests create two real organizations and then try to cross the wall on every route, which we describe below.
5. Database-level locks. Two triggers hold even if application code is wrong: a project can never be moved to another organization, and an administrator token can exist only in the platform organization. Exactly one platform organization is allowed to exist.
6. A git wall. Each organization's SSH keys are written into the server's key file with an explicit list of that organization's repositories. A repository outside the list is indistinguishable from one that does not exist.

What the attack suite actually attempts

• Reading every project route, eleven in all, with another organization's project name, and comparing the answer to a project name that does not exist. They must match exactly.
• Writing to the other organization's project through every writing route: environment variables, scheduled jobs, domains, backups, restores, rollbacks, database provisioning. Each must fail, and the victim's data must be unchanged afterward.
• Looking up another organization's build, build logs, backups, tokens and keys by identifier.
• Restoring another organization's backup through the attacker's own project, and restoring a backup from a different project in the same organization through the wrong project.
• Smuggling another organization's identifier in a request body, a header and a query string, and checking that the record ends up owned by the caller regardless.
• Squatting another organization's project name, and claiming a domain name another organization already attached.
• Escalating: a member minting tokens, an owner minting an administrator token, tenant tokens reaching organization administration, host status or alerts.
• Operating on a disabled organization, whose tokens must stop working instantly, and exceeding a project limit.

Passing a test suite proves little if the tests cannot fail, so the walls were broken on purpose. Eight different protections were removed one at a time, and the suite caught every one of them. Finally, the same attacks were run against the real, deployed API using two throwaway organizations, which were then deleted. The result was the same: not found, forbidden, or unchanged.

A security section should be a list of specific controls, not a mood. These are the ones that exist today.

How it is tested

Each control above has a test that tries to defeat it, and the design deliberately favors proven components over novel ones. Independent penetration testing and compliance certifications are not part of early access. If your application handles regulated data, we will go through your requirements with you before you start.

Claims are cheap. The first application moved onto Stackap was The NYC Classifieds, a pre-launch Next.js website that verifies every member with a selfie and a location check at their New York address. It has 31,592 pages in its sitemap, a Postgres database of 43 tables, user-uploaded images, email-based sign-in, and an advertiser. It was hosted on a deployment platform and a hosted database, and it was moved to Stackap. Here is how it went.

Staging first, production untouched

The site was copied onto Stackap as a staging site on its own address while the live site kept serving. The staging build took about 96 seconds on the server. The environment was deliberately inert: messaging and payment switches were off and provider keys were dummies, so a staging site could not email, text or charge anyone.

The data

The migrator copied the live database's public schema and data using SELECT statements only. It found something the repository's migration files did not mention: six tables existed only in the live database, created by hand at some point. The migrator rebuilt them from the live catalog. The lesson is one every migration teaches again: the running database, not the code repository, is the truth about what exists. The first copy was 24,972 rows. The final copy, taken shortly before the switch, was 24,988 rows across 43 tables with zero mismatches between source and target.

The files

The site stores 93 uploaded files, about 57 MB, in two storage buckets. They were downloaded, uploaded to Stackap's storage, then read back through the storage API and compared by SHA-256 checksum against the originals: 93 of 93 matched. Sixty image addresses stored in forty-two database rows were rewritten to the new storage location, and a scan of every text, JSON and array column in the database found none left pointing at the old host.

Comparing the two sites

Rather than eyeball it, the two sites were fetched page by page and compared after normalizing the host name and deployment hashes. First pass: every status code matched, but a few hundred bytes of CSS differed on every page. The cause was that the staging copy had been built from a local branch that was five commits behind what the live site was actually running. The comparison caught it before anyone else could. After rebuilding from the right commit, twenty-six key pages, sixty-four randomly sampled data pages and the CSS bundle itself matched exactly, and later a full pass of 87 pages did too. Screenshots of the home page, the neighborhood board and the sign-up page, taken from both sites, were visually identical.

The part nobody can skip: a real sign-up

Pages rendering is not the same as the product working. On the new server, using the real domain, a complete sign-up was run: request an email code, receive it, verify it, create an account with an address and a selfie, store the selfie, log in with a PIN, get refused with a wrong PIN, read the session, upload a photo. The verification email genuinely arrived, from the site's own address, with the right code inside. The test account and files were then deleted, and a count confirmed none remained.

The switch

The cutover is one DNS change, made by the owner at a moment he chooses. Two details matter. Lower the record's cache lifetime to five minutes a day beforehand, so visitors follow the change quickly. And make the edit replace the existing address record rather than add a second one, so visitors never alternate between the old and new hosts. Keep the old host and database running as a fallback for a week, and switch off the old host's scheduled jobs the same hour so that nothing runs twice.

How to move your own application

The sequence that worked is general. It is also the checklist the migrator and the comparison tools were built around, so you can follow it for an application of your own.

1. Inventory. List the environment variables, scheduled jobs, webhooks, domains and storage buckets the application depends on. The code tells you what it reads; the running platform tells you what is actually set. They are rarely identical.
2. Lower the DNS cache lifetime on the domain to five minutes, a full day before the switch.
3. Stand up a staging copy on Stackap with messaging and payments switched off.
4. Copy the data with the read-only migrator, and verify counts table by table.
5. Copy the files, verify them by checksum, and rewrite stored addresses. Then scan every column for leftovers.
6. Compare page by page against the live site, normalizing host names, until the differences are explained or gone.
7. Run the real flows end to end, on the real domain, pinned to the new server before DNS moves.
8. Switch, then verify, then silence the old side. Change the single record, check every flow again, and turn off the old platform's scheduled jobs the same hour. Keep the old stack running for a week as a fallback.

These are the benefits we have felt while building and using it.

One place to look

Code, builds, logs, databases, files, schedules, backups and alerts live behind one API, one command-line tool and one dashboard. When a customer says the site is slow, there is one place to start.

A deploy is a push

No pipeline files, no queue to wait in, no separate budget that can run out and silently stop your deploys.

Predictable cost

A server has a price, not a meter. A traffic spike makes the machine busier, not the invoice larger.

No lock-in

Postgres, Docker, git, Caddy, and files in a bucket you own. Your data sits in a database you can dump with standard tools, your backups are in your own account, and the Supabase-compatible layer means your application code does not change on the way in or on the way out.

Compatibility, not conversion

Applications written for the Supabase client keep working for data and storage, vercel.json schedules import as they are, and a Next.js project builds with no Dockerfile. The move is mostly configuration, not rewriting.

Backups you have actually restored

Verified restores on a schedule, row counts compared, failures alerted.

Control of where data lives

You choose the server's country, and the same software runs wherever you put it.

Isolation you can offer

Because organizations are walled apart, one box can serve clients, teammates or customers. Hosting becomes a service you can offer, not only a cost you bear.

Visible failure

Unhealthy deploys never go live, missed jobs are recorded, and unverified backups are not called verified.

Built to be driven by agents

Everything the dashboard does is an authenticated API call. That makes the platform easy to automate, and easy for a coding assistant to operate on your behalf.

How it differs from a stack of hosted subscriptions

The compare section goes product by product.

Stackap has not launched publicly. A limited number of teams are invited in early access, each onboarded by hand, so the platform grows around real applications and not imagined ones. Here is what that means in practice.

What early access includes

• A Stackap server of your own, or an organization on the founder's, with a token, a git key and a dashboard.
• Git deploys, HTTPS, per-project Postgres, file storage, scheduled jobs, logs, monitoring and encrypted backups, all described in the product section.
• Recognized project types: Next.js, single-page apps (Vite, Create React App, Vue CLI, Parcel), static-output sites (Astro, Docusaurus, Gatsby, Eleventy, VitePress), plain HTML, and any Node app with a start script, or anything with a Dockerfile.
• Hands-on onboarding. Migrations are done with you: an inventory, a staging copy, a page-by-page comparison and a cutover you approve.
• A direct line to the person building it.

Scope today

These are the boundaries of early access, so you can judge fit before you ask. Each one is also stated on the relevant product page.

One server, one region

Everything runs on a single machine, today in Germany, and a different location is a matter of choosing a different machine. Up to eight copies of an app share the server's cores behind a load balancer.

Daily backups

Databases and the control plane are backed up daily to a bucket you own, restore-verified weekly. Point-in-time recovery is on the roadmap.

Data and storage, not sign-in

Stackap provides the Postgres database, the Supabase-compatible data API and storage. Applications bring their own sign-in, and realtime and edge functions are not part of the platform.

Organizations created by the operator

Tenant code runs on the same host in resource-limited containers, so organizations are created by the operator for teams that are known and trusted.

Deploys from the production branch

Pushes to the production branch build and go live once healthy. Branch previews and a built-in test gate are on the roadmap, so run your tests before you push.

No independent audit yet

Independent penetration testing and compliance certifications are not part of early access. If your application handles regulated data, we will go through your requirements with you first.

Stackap fits best if

• You run several applications, and your hosting, database and storage have spread across several vendors.
• Someone on your team is comfortable with a terminal and a server, or you work with a coding assistant that is.
• Your applications are standard: Next.js or any container, Postgres, files, some scheduled jobs.
• You value owning the stack and being able to leave.
• You host sites or tools for clients and would like to do it from one controlled place, for people you trust.

Ask for an invitation