# Stackap > Stackap is a platform you own: git deploys, HTTPS, Postgres, storage, cron jobs and encrypted backups on one server, operated by your coding agent. Source: https://www.stackap.com/ (last updated 2026-10-03). This file is the full text of the home page, followed by every other page on the site. www.stackap.com · a platform you own # Your whole stack. No DevOps. Build today. Live today. Stackap gives your coding agent everything it needs to build, deploy and operate production applications, from compute and databases to domains, storage, monitoring and backups. Early access, invite-only. Best with a terminal and a DNS record at hand; the FAQ has the details. This page is served by Stackap. ## See it happen YouPut this app into production using Stackap. AgentDone. https://myapp.com is live. An illustration of the idea. Below is what the agent runs: the commands are real, and the progress lines summarize what the platform does. ## Everything included - Build & deploy - Database - Storage - Domains - HTTPS - Crons - Secrets - Logs - Metrics & monitoring - Backups - Rollbacks - Scaling Coming next in the same place: phone service · email service · financial services ## Looking for an alternative? - Vercel alternative - Heroku alternative - Supabase alternative - Railway alternative - Render alternative - Deploy a Next.js app ## What it replaces Today - Idea - Claude - GitHub - Vercel - Supabase - Cloudflare - Settings - Keys - DNS - More settings - Debugging - Production Stackap - Idea - Agent - Stackap - Production The top row is the path many agent-built apps take today. The bottom row is the goal. Where it falls short of the services it replaces is stated plainly. - ~700 requests per second from one four-core server on real pages, with no errors - 96 s to build a 31,592-page Next.js site on the server - 24,988 database rows moved, zero mismatches; 93 of 93 files verified - 43 / 43 cross-organization attacks refused by the tenant walls How to read this page: it is long on purpose, because the question it answers is large. Each section stands alone, so jump to the one you care about from the contents. Every number is measured, taken from a real bill, or labeled as an estimate. Last updated October 3, 2026. 01 / The short version ## If you read nothing else, read this. 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. The three sentences Stackap replaces a stack of hosted services with one server you own. It is built so that a coding agent can take an application from a repository to a live domain, and then operate it. It is in early access, with a limited number of teams invited. ### 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. 02 / What it is ## One server that does the job of a whole stack. 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 The whole workflow. There is no pipeline file to write, no dashboard to click through, no merge queue to wait on. 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. Job | Usually a subscription to | In Stackap | Hold the code | A git host | Bare git repositories on the box, reached over a locked-down SSH user | Build and deploy | A deployment platform | Docker builds on the box, health-checked swap, one-command rollback | Domains and HTTPS | The same platform | Caddy with automatic Let's Encrypt certificates, routing that only switches on once DNS is correct | Database | A hosted Postgres | A private Postgres database and login role for every project | API over the database | The same hosted service | PostgREST, compatible with the Supabase JavaScript client | File storage | The same hosted service | The official Supabase storage service, writing to a Cloudflare R2 bucket you own | Scheduled jobs | A cron add-on | A built-in scheduler that can import a vercel.json as it stands | Backups | An add-on tier | Encrypted, snapshot-consistent, restored and verified on a schedule | Monitoring and alerts | An uptime service | Ten built-in checks and Telegram alerts, with reminders and recovery messages | Teams and clients | Seat licences, per-user pricing | Organizations, roles, per-organization git keys and project limits | ### 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. 03 / Why one stack ## The cost of assembling a platform. 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. 04 / Why it exists ## Because the economics of building platforms changed. 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 founder's reasoning ### 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. 05 / How it works ## From git push to live, step by step. 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. A push, end to end. The only step that changes what visitors see is the last one, and it only runs if every step before it passed. ### 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. Tested the unpleasant way The deploy path was exercised with a deliberately broken release. The broken build never went live, the previous version kept serving, and the failure was recorded where you can see it. A system that only works when everything works is not a platform; it is a demo. ### 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. 06 / What is in the box ## Every part, and what it really does. 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 small true story While this page was being written, a monitoring alert flagged three scheduled jobs as failed. They had not failed. The scheduler had recorded "missed" runs for fire times that predated the jobs' existence, because a freshly imported job looked, to the scheduler, like one that had been neglected. The fix was a rule that a job with no history cannot have missed anything, a test that fails without it, and a deploy. The alert system did its job by being annoying about a real bug. 07 / Multi-tenant ## One box, many organizations, solid walls. 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: - 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. - 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. - 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. - An attack suite. Forty-three tests create two real organizations and then try to cross the wall on every route, which we describe below. - 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. - 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. What the walls do not cover These walls keep one organization's data and controls away from another's. They do not sandbox the code an organization deploys. That code runs in containers on the same machine, and containers are not a security boundary against a determined attacker. Until builds are sandboxed, creating organizations is an operator action, meant for people you trust. Postgres row-level security as a second lock under the application wall is the next planned layer. 08 / Security ## What is locked, and how. A security section should be a list of specific controls, not a mood. These are the ones that exist today. Area | Control | Network | Only SSH, HTTP and HTTPS are open to the internet. Postgres listens on localhost and the internal container network only; its port is closed to the outside. A firewall and an intrusion-banning service run on the host. | Secrets at rest | Environment variables and database connection strings are encrypted with AES-256-GCM under a master key and bound to their project and name. Access tokens are stored only as SHA-256 hashes, so a database leak does not reveal usable tokens. | Secrets in motion | Secrets are passed to containers through a private, mode-0600 environment file, never on the command line where any process listing could read them. | Git access | A restricted SSH user with a forced command. No shell, no port forwarding, no arbitrary commands. Per-organization repository allow-lists. | Internal endpoints | The push hook accepts only localhost connections and requires a shared secret compared in constant time. | Containers | No new privileges, CPU, memory and process-count limits on every container. Generated images run as an unprivileged user. | Databases | One role per project, no superuser rights, no ability to create roles or databases, connection rights limited to its own database. | Backups | Encrypted before upload, authenticated against tampering, restore-only-into-new-databases. | Dashboard | Static files under a strict content-security policy, rendering data only as text, never as markup. | Audit | Pushes, deploys, rollbacks, token and key changes, backups, restores and organization actions are recorded with who did them. | ### 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. 09 / Proof ## The first move: a real site, real data, real visitors. 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. What was checked | Result | Database rows, source versus target | 24,988 / 24,988, 0 mismatches | Files, checksum against the original | 93 / 93 | Pages identical to the live site | 87 / 87 | Old-host image references remaining | 0 | End-to-end sign-up, including email | Passed; test data removed | Cross-organization attacks refused | 43 / 43, plus a live run on the deployed API | ### 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. - 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. - Lower the DNS cache lifetime on the domain to five minutes, a full day before the switch. - Stand up a staging copy on Stackap with messaging and payments switched off. - Copy the data with the read-only migrator, and verify counts table by table. - Copy the files, verify them by checksum, and rewrite stored addresses. Then scan every column for leftovers. - Compare page by page against the live site, normalizing host names, until the differences are explained or gone. - Run the real flows end to end, on the real domain, pinned to the new server before DNS moves. - 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. 10 / Benefits ## What owning your stack gives you. 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 Question | Several hosted subscriptions | Stackap | Shape of the bill | Metered: usage, seats, add-ons | Flat: one server | Places to look | Three or more dashboards | One | Where the data lives | The vendor's cloud | Your server and your bucket | Leaving | Possible, with migration work | Standard parts, designed for it | Who operates the host | The vendor | You, helped by alerts | Location | The vendor's regions | Wherever you put the server | Hosting for clients or teammates | Per-seat and per-project pricing | Organizations, roles and limits built in | Time to first deploy on a new project | Minutes | Minutes, once the server exists | The compare section goes product by product. 11 / Early access ## Invite-only, and built with its first teams. 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. 12 / Who it is for ## The teams it fits best. ### 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. A quick test If your applications are conventional web apps with a database, and you would like one place to deploy and operate all of them, tell us what you run and we will say whether early access fits. Teams that need a global edge network, certified infrastructure or per-branch preview environments today are better served by a hosted platform for now, and we will say so. Ask for an invitation 13 / What is next ## Where it is going. This is the direction, in rough priority order. It is a statement of intent, not a promise of dates. ### Beyond hosting The larger plan is one place for the whole operating side of a small business, in this order: a phone service and an email service, then financial services. All three are in development and none is part of early access yet. They are built on the same platform, behind the same tokens, audit log and agent-operable interface. See the roadmap. ### On the platform - A full rebuild drill on a fresh machine. Prove that, with the server gone, everything comes back from the bucket and a copy of the master key. - The larger multi-tenant CRM, the founder's own scale test. - Point-in-time recovery for databases, shrinking the worst-case data loss from a day to minutes. - Row-level security as a second database-level lock beneath the tenant wall. - Sandboxed builds and runtime, which opens organization creation to more teams. - A standby server for fast failover. - Preview deployments and an optional test gate before a push goes live. - A job queue for background work, and more than one application server. 14 / Get access ## Ask for an invitation. Stackap is in early access and invitations are limited. If you run several applications and want to see whether a platform like this fits, tell us what you run. We will reply with a straight answer about whether Stackap would help. Leave this field empty NameEmailCompany optionalWhat do you run today?Roughly what do you pay for hosting each month? optionalHow can we help?Request an invitation We read every message and reply by email. Your details are used only to reply to you; see the privacy notice. --- Source: https://www.stackap.com/company/ Company # Company Stackap is one founder and an AI coding assistant, building a platform to remove the infrastructure steps that stall agents. Stackap is one founder and an AI coding assistant, building a platform to remove the infrastructure steps that stall agents. These pages cover the origin, the principles, security, reliability and how to get in touch, with the weaknesses stated alongside the strengths. ## Pages in this section - About: Why Stackap exists: software creation changed, infrastructure operation did not, and one founder built a platform so agents can do the operating. - Mission: Stackap's mission and the four engineering principles behind it: do not send the human to a setting, courier, or diagnosis; documentation bugs are real bugs. - Security: The security controls built into Stackap today, how the walls between organizations are tested, and how regulated workloads are handled in early access. - Reliability: How Stackap keeps a site up and recovers: health-checked deploys, one-command rollback, monitoring and alerts, replicas, and backups that are restore-verified. - Contact: Ask for an early-access invitation to Stackap: tell us what you run and we will reply by email with a straight answer about whether it fits. - Roadmap: Where Stackap is going: hosting today, then a phone service and an email service, then financial services, all in one place that an agent can operate. - Privacy: What happens to the details you send through the Stackap contact form, what the website does and does not track, and how to ask us to delete your message. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/about/ Company # About Stackap Stackap exists because building software got easy and operating it did not: you can tell an agent to build an app, and minutes later be told to go and create an account somewhere. ## Where it came from We got tired of deploying apps across five different companies. A single product could involve a code host, a deployment platform, a database provider, a storage service and a DNS panel, each with its own account, its own keys and its own bill. The founder runs several products, one of them a multi-tenant CRM serving roughly a hundred businesses, and the infrastructure around them had become a job of its own. ## What changed Software creation changed. Infrastructure operation largely did not. People can now tell a coding agent, build me this, and get a working app. And a few minutes later the same agent says: now go and create a Supabase account. That is the absurdity Stackap exists to remove. ## What it is Stackap is a platform for building, deploying and operating production applications from one place. It hosts git, deploys with health checks, issues HTTPS certificates, gives each project its own Postgres database, stores files, runs scheduled jobs, backs up to a bucket you own and watches itself. It hosts several organizations on one server with walls between them, and it is designed so that an agent can drive all of it. It is a new company and a new platform, and it has not launched publicly. The ambition is larger than hosting: a small business should run on one place, with phone and email next and money after that, all of it operable by the same agent. The roadmap page lays out the order. A limited number of teams are invited in early access, onboarded by hand, so the product is shaped by real applications. The early-access page says what is included today, and the contact page is how to ask for an invitation. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/contact/ Company # Contact and early access Tell us what you run and we will reply by email with a straight answer about whether Stackap fits. ## Ask for an invitation Stackap is in early access and invitations are limited. A person reads every message. If it looks like a fit, you will hear what the next step is, which today means an organization and a token created for you and a first migration done together. If it does not look like a fit, you will hear that too. Leave this field empty NameEmailCompany optionalWhat do you run today?Roughly what do you pay for hosting each month? optionalHow can we help?Request an invitation We read every message and reply by email. Your details are used only to reply to you; see the privacy notice. Prefer email? Write to hi@stackap.com. ## What happens next We reply by email, and a call is optional. If it looks like a fit, a first migration is done together: an inventory of what you run, a staging copy, a page-by-page comparison with the live site, and a cutover that you approve. Your details are used only to reply to you. ## What helps us reply well - Roughly how many applications you run and what they are built with. - Which services you use today for hosting, database and storage. - Whether any of them uses a hosted sign-in service, since Stackap does not provide one. - Whether your data is regulated, so we can talk it through first. ## Security reports Send them to hi@stackap.com with what you found and how to reproduce it, and please test only systems that are yours. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/mission/ Company # Humans decide. Machines operate. Building software should not require becoming an infrastructure operator: humans express intent and authorize what matters, and agents do the repetitive technical work on infrastructure designed for them. ## The position Humans should decide. They should express intent, make judgments and authorize important decisions. Agents should handle the repetitive technical work. Stackap exists to give those agents an infrastructure platform designed for them, so that the person's attention goes to what to build and whether to ship it. ## Four principles **Don't send the human to a setting.**: If an operation can be a command, it is a command. A step that only exists as a switch in a web page is a step an agent cannot take. **Don't use the human as a courier between machines.**: Copying a key from one dashboard into another is not judgment. Stackap keeps the pieces in one place so nothing has to be carried. **Don't make the human diagnose something the agent can inspect.**: Build logs, runtime logs, health and metrics are readable by the same tools that deploy, so a failure can be understood without a person describing a screen. **If the agent has to guess, the documentation has a bug.**: Documentation is part of the product. Gaps in it are defects, filed and fixed like any other. ## Where people stay in the loop Deploying to production, pointing a domain, rolling back and anything destructive remain a person's call. The aim is for those to be the only moments that need a person at all. Everything else is built to be done for you, and to be done the same way every time. This is built into the platform, not left to good intentions. An agent holding an approval-mode token that tries a risky action, today deleting a project, is stopped with an approval_required answer. A link goes to the account owner by a separate channel, never through the API. The owner sees exactly that one action and approves or denies it. An approval covers only that exact request, works once, and expires after an hour, so an agent can neither reuse it nor nag for it. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/privacy/ Company # Privacy This website collects only what you type into the contact form, uses it only to reply to you, and sets no cookies and runs no analytics or third-party scripts. ## What the website tracks Nothing. The pages set no cookies, load no analytics and no advertising scripts, and load no fonts, images or code from any other company. The only script on the site is Stackap's own, and it handles the reading-progress bar and the contents list. ## What the contact form collects - The name and email address you enter, and the optional company, description of what you run, and hosting spend, plus the message itself. - The page you sent the form from, and your browser's user-agent string. - A one-way hash of your network address, used only to limit how many messages one connection can send in an hour. The address itself is not stored. ## What we do with it We read your message and reply to you by email. Messages are stored in Stackap's own database on a server in Germany, visible only to the operator through the admin dashboard. Each new message also triggers a notice to the operator's Telegram account containing the details you submitted, so Telegram is the one outside service that sees them. We do not sell your details, share them for marketing or add you to a mailing list. ## Asking us to delete or correct your message Write to hi@stackap.com from the address you used and say what you would like removed or corrected. We will handle it and tell you when it is done. ## Who is responsible Stackap is operated by its founder. Questions about this page, or about anything you have sent, go to hi@stackap.com. This page describes what the website actually does today and will be updated if that changes. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/reliability/ Company # Reliability Stackap protects a running site from bad deploys, watches itself, and proves its backups restore. ## What protects a running site - A new version never receives traffic until it passes a health check, so a bad build or a crashing container leaves the old version serving. - Rollback is one command and health-checks the earlier version first. - A project can run up to eight copies behind a load balancer with failover. A copy that was killed during a test caused no failed requests. - Docker logs rotate, and a daily job prunes old build cache and images, so a disk does not fill silently. ## What watches it A monitor checks the platform and every project, including backups and the control plane, and sends alerts to Telegram. A failing check repeats its alert every six hours until it is resolved, so a missed message is not a missed problem. ## What has been proven - Backups of every project database and of the control plane are restore-verified, and restoring onto a separate machine using only the bucket and the master key has worked. - One real Next.js site has been copied onto Stackap and compared with the live original, with 26 pages and 64 sampled sitemap URLs identical. - A load test on one 4-CPU server reached roughly 700 requests per second on real pages with no errors. ## What is next Early access runs on one server in one region, with daily backups. The roadmap adds a full rebuild drill on a fresh machine, point-in-time recovery and a standby server. The steps for a full rebuild are written down in a runbook, and the drill is how that runbook gets proven. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/roadmap/ Company # One place for the whole operating side of a business Stackap starts with hosting and is growing into one place for the rest of a small business's operating work: a phone service and an email service next, then financial services. ## Why one place A small business does not run on one product. It runs on a website, a phone line, an inbox and a set of books, each from a different company with its own login, its own bill and its own way of failing. Every seam between them is something a person has to carry: a key copied here, a number configured there, a report exported from one place and typed into another. Stackap's bet is that the same design that removes those seams for hosting removes them for the rest of the operating side too. ## The order **Now: hosting**: Git deploys, HTTPS, Postgres, storage, scheduled jobs, logs, monitoring and encrypted backups, with walled organizations and approvals for risky actions. This is in early access today, and the product pages describe it in detail. **Next: a phone service and an email service**: Both are in development and are not part of early access yet. They are being built on the same platform, so a customer's calls, texts and email sit next to the application they belong to, behind the same tokens, the same audit log and the same agent-operable interface. **After that: financial services**: The money side of running a business, in the same place as everything else. It follows phone and email, and the details are being worked out with early-access teams. ## What stays the same as it grows - One place to look. One account, one dashboard, one command-line tool and one API for every service. - Agent-operable. Everything a person can do through a screen is also a command and an API call, with scoped tokens and a human approval for anything risky. - You own the data. Standard formats, in accounts you control, with backups you can restore and a way out. - Walls between organizations. Each new service inherits the same isolation that keeps one organization's data away from another's. - Nothing is called available until it has been used for real. The site will list phone, email and financial services as available only when they are. ## How to take part Teams in early access hear about each new service first and help decide how it works. Tell us what you run, and what you would like to stop juggling, on the contact page. Last updated 2026-10-03. --- Source: https://www.stackap.com/company/security/ Company # Security Stackap's security is a list of specific controls, each with a test that tries to defeat it. ## Controls built in **Network**: Only SSH, HTTP and HTTPS are open. Postgres listens on localhost and the internal container network only. **Secrets at rest**: Environment variables and connection strings are encrypted with AES-256-GCM, bound to their project and name. Access tokens are stored only as SHA-256 hashes, so a database leak does not expose usable tokens. **Secrets in motion**: Secrets reach containers through a private, owner-only file, never on a command line. **Git access**: A restricted SSH user with a forced command: no shell, no port forwarding, no arbitrary commands. Each organization's keys reach only its own repositories. **Containers**: No new privileges, CPU, memory and process limits, and generated images run as an unprivileged user. **Databases**: One role per project, no superuser rights, and connection rights limited to its own database. **Backups**: Encrypted before upload, authenticated against tampering, and restorable only into new databases. **Tokens**: Scoped, expiring and rotatable, so an agent can be given exactly the permissions a task needs. **Human approval**: With an approval-mode token, a risky action such as deleting a project stops until the account owner approves that exact request through a link sent out-of-band. An approval is single-use, bound to the exact action, and expires after an hour. A project deletion is recoverable: code, database and backups are kept. **Audit**: Pushes, deploys, rollbacks, token and key changes, backups, restores and organization actions are recorded with who did them. ## How the walls between organizations are tested Every lookup of a project, build, backup, token or key goes through one module that filters on the caller's organization, taken from the token alone. A static test reads every route and fails the build if any query touches tenant data without that filter, and the test itself is checked with deliberately leaky examples. An attack suite attempts 43 cross-organization actions, and all are refused. A resource in another organization returns the same response as one that does not exist. ## Early access and regulated workloads Organizations are created by the operator for known teams, because tenant code shares one host in resource-limited containers. 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. To report a problem, write to hi@stackap.com. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/ Compare # Compare Factual comparisons of Stackap with hosted platforms, written to say where each one is the better choice. Factual comparisons of Stackap with hosted platforms, written to say where each one is the better choice. Each page states when facts about other products were last checked, avoids quoting prices that change, and lists what Stackap lacks as plainly as what it offers. ## Pages in this section - Vercel alternative: A Vercel alternative that runs on a server you own. Check what you rely on first: previews, edge and functions do not move; git deploys, cron and domains do. - Supabase alternative: A Supabase alternative for the data side: tables, rows, the data API and storage carry over; sign-in, realtime and edge functions do not. A feature checklist. - Railway alternative: A Railway alternative for a fixed server cost: one container and a private Postgres per project, with no multi-service canvas. What you give up. - Render alternative: A Render alternative for web services, static sites and cron jobs on a server you own: what maps across, what does not, and what a move involves. - Heroku alternative: A Heroku alternative with git-push deploys, Postgres and cron on your own server. Procfile and dynos versus containers; add-ons versus built-in services. - Vercel and Supabase alternative: Stackap does the deploy half of Vercel and the Postgres and storage half of Supabase on one server you own. What it replaces, and what it does not. - Vercel vs Stackap: A factual comparison of Vercel and Stackap for deploying web apps: what each handles, who runs the servers, and where the trade-offs sit. - Supabase vs Stackap: A factual comparison of Supabase and Stackap for Postgres, storage and APIs: what each provides, what Stackap lacks, and when each is the better choice. - Railway vs Stackap: A direct comparison of Railway and Stackap on billing, project shape, databases, scaling and operations, written to say where each is the better pick. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/heroku-alternative/ Compare # A Heroku alternative, and what replaces dynos and add-ons Stackap is an alternative to Heroku for web apps that want git-push deploys, Postgres and cron on a server they own, with containers and copies in place of dynos, and no add-on marketplace. ## The short answer Heroku popularized the push-to-deploy loop that Stackap also offers. The vocabulary is what differs: Heroku has buildpacks, a Procfile, dynos and add-ons, while Stackap has a Dockerfile or a recognized project type, containers, copies and a short list of built-in services. If your app is a web process and a Postgres database, translation is straightforward. If it leans on many add-ons or on worker dynos, there is more to replace. One thing to check before anything else is the release phase. Many Heroku apps run database migrations there. Stackap has no release phase, so migrations move into a script you run before deploying, or into the app's own start-up, written so that running twice is safe. ## Side by side Heroku concept | Stackap equivalent | Gap | Buildpacks | Generated Dockerfile for Node and static projects | No buildpacks for other languages; bring a Dockerfile | Procfile process types | One web process per project | No worker or release process types | Dynos and scaling | Copies, 1 to 8, on one server | Operator-set, no autoscaling | Heroku Postgres | A private Postgres per project | No follower databases, no point-in-time recovery yet | Add-ons marketplace | Built-in storage, cron and backups | No marketplace | Review apps and pipelines | None | Use a staging project | Scheduler | Cron: scheduled calls to a path | UTC only | Config vars | Encrypted environment variables | No reveal, no history | ## Choose Heroku if - You depend on several add-ons for logging, search, queues or email that have no built-in equivalent here. - You run worker dynos or release phases. - You use pipelines and review apps as part of your release process. ## Choose Stackap if - Your app is a Node or static project, or already has a Dockerfile. - You want a fixed cost for the whole fleet of small apps. - You want to own the database encryption and the backup bucket. ## What the money looks like Heroku prices dynos and add-ons by plan, and prices change, so read its pricing page. The shape of the saving is the same as elsewhere: Stackap sells the software and you buy the capacity directly. Add-ons are where hidden cost sits on a long-lived Heroku app. List every one before you compare, and decide for each whether Stackap's built-in service, a separate provider or nothing replaces it. ## Early-access scope - No add-on marketplace, so each add-on has to be replaced individually. - No languages beyond Node and static without a Dockerfile. - No review apps, pipelines, worker dynos or release phases. - Backups are daily, with no point-in-time recovery. ## Questions **Q: What is the best alternative to Heroku?** For a Node or static web app and a Postgres database, Stackap gives you the same git-push loop for the cost of a server. For apps built on worker dynos and many add-ons, a hosted platform is closer. **Q: Does Stackap read my Procfile?** No. It looks at package.json or a Dockerfile. A web process becomes a start script. **Q: Can I scale like dynos?** Only in one way: an operator can run one to eight copies of the web process on the server. There is no per-process-type scaling and no autoscaling. **Q: How do I run migrations?** Run them as a script before you deploy, or at the app's start-up in a way that is safe to repeat, since there is no release phase. **Q: Where do my add-on settings go?** Into environment variables, set one at a time, for whatever replaces each add-on. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/railway-alternative/ Compare # A Railway alternative on a server you own Stackap is an alternative to Railway for people who want a fixed server cost instead of metered usage, with one container and one private Postgres per project, and no multi-service canvas. ## The short answer Railway is a hosted platform that deploys from a repository or an image, runs several services side by side inside a project, and offers managed databases, billed by what you use. It is built around a visual project that holds many things. Stackap makes a different trade. A project is one app with its own database. If your system is one web app and one Postgres, that is enough. If it is five services talking to each other, Stackap does not model that today. Where the one-container limit bites is easy to count. A web app, a separate API, a worker and a cache are four things on Railway's canvas. On Stackap they become two projects, the worker has to be reshaped into something with an HTTP port, and the cache has nowhere to live except the database. ## Side by side | Railway | Stackap | Where it runs | Railway's infrastructure | A server you rent | Shape of a project | Several services and databases together | One app, one database | Deploy source | A repository or an image | Stackap's own git, or a Dockerfile in it | Services talking privately | Supported | Not a feature | Managed databases beyond Postgres | Several kinds | Postgres only | Background workers with no port | Supported | Not included; apps must serve HTTP | Scheduled jobs | Supported | Yes, HTTP calls to a path, UTC | Cost shape | Metered usage | The price of the server | ## Choose Railway if - Your system is made of several services that need to reach each other privately. - You want databases other than Postgres, or workers that run without a web port. - You like deploying and reshaping infrastructure on a visual canvas. ## Choose Stackap if - Each of your apps is a web app with its own Postgres. - A predictable monthly bill matters more than elastic capacity. - You want encrypted, restore-verified backups going to a bucket you own. - You are fine with one server and the single-machine limits that come with it. ## What the money looks like Railway is billed by usage and its pricing changes, so read it before you compare. Stackap's cost follows the server you choose, so a steady, busy app has a predictable bill. Metered billing can be cheaper than a server for an app that is mostly idle, and a fixed server can be cheaper for an app that is busy. Work out which your app is before you assume either. ## Early-access scope - There is no multi-service project, no private networking between apps and no database but Postgres. - Background workers without an HTTP port cannot pass the health check. - One server means one failure domain. - Stackap is in invite-only early access. ## Questions **Q: Can I run a worker next to my web app?** Not as a separate service. A worker that exposes a small health endpoint could run as its own project, but we have not tested that pattern. **Q: Is a Docker image deploy supported?** Stackap builds from your repository, using your Dockerfile if you have one. Pulling a prebuilt image from a registry is not a feature. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/railway-vs-stackap/ Compare # Railway vs Stackap Railway bills what your services use on infrastructure it runs; Stackap runs on one server you rent at a fixed price, and the difference shapes everything from cost to how you scale. ## The short answer The cleanest way to compare them is to ask what happens when your app gets ten times busier. On Railway, you are billed for the extra usage and the platform finds the capacity. On Stackap, the app gets more copies on the same server until the server is full, and past that you need a bigger server or a second one, which is not built. And the reverse question, what happens when your app is idle? Railway's bill falls toward nothing, while a Stackap server costs the same whether it is busy or not. The other difference is who does the unglamorous work. On a hosted platform, patching the host, replacing failed hardware and watching capacity are someone else's job. On Stackap they are yours, helped by a monitor that checks CPU, memory, disk, certificates and backups, and alerts you, but cannot replace the hardware. ## Side by side | Railway | Stackap | Capacity | Elastic, billed by use | Fixed at one server; 1 to 8 copies of an app | Idle cost | Falls with usage | The server price, always | Busy cost | Rises with usage | Flat until the server is full | Ceiling | The platform's limits | About 700 requests per second per 4-CPU server on one measured site | Failure domain | Spread by the platform | One server | Backups | Provided by the platform | Daily, encrypted, restore-verified, to your bucket | Who patches the host | Railway | You | Data location | Where the platform places it | Where you rent the server | ## Choose Railway if - Your traffic is spiky and you do not want to size a server for the peak. - You want someone else to patch the host and absorb hardware failure. - You run many services that talk to each other. ## Choose Stackap if - Your traffic is steady and fits on a four-core machine. - You want to know your monthly bill in advance. - You want your own encryption key and backup bucket. ## What the money looks like There is no universal winner. A mostly idle app is cheaper on usage billing. A steadily busy app, or a fleet of small ones, is cheaper on a fixed server. Take your last three months of usage on Railway, find the busiest week, and check that week against the one measured figure of about 700 requests per second per server. If you are far below that, a fixed server probably costs less. ## Early-access scope - Stackap has no elastic capacity and no multi-server scaling. - One server is one failure domain, and a full rebuild from nothing has not been tested. - The 700 requests per second figure is from one test of one site's pages and is not a promise for yours. - Stackap is invite-only early access. ## Questions **Q: Which is cheaper?** It depends on how busy your app is, as the section above explains. Check your own numbers, not ours. **Q: Can I move gradually?** Yes, one project at a time. Each app and its database moves on its own. **Q: Can I mix the two?** Yes. Keeping a spiky or multi-service system on Railway and moving steady, simple apps to a fixed server is a reasonable split. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/render-alternative/ Compare # A Render alternative for web apps and static sites Stackap is an alternative to Render for web services, static sites and scheduled jobs on a server you own, but it has no background workers, no previews and no managed multi-region hosting. ## The short answer Render is a hosted platform with a few clear service types: web services, static sites, background workers, cron jobs and managed Postgres. That vocabulary makes a comparison easy, because Stackap covers some of those types and not others. Web services and static sites map across directly. Cron jobs map across with a different mechanism. Background workers do not map at all today, and that is the thing to check first. One difference is invisible until it matters: where builds run. On Render a build happens on its infrastructure and does not touch your running service. On Stackap a build runs on the same machine as your live apps, so a heavy build for one project can briefly slow another. ## Side by side Render service type | On Stackap | Note | Web service | Yes | A container that listens on PORT, built from your Dockerfile or a recognized project | Static site | Yes | Built and served from nginx, real 404s | Background worker | Not included | Needs an HTTP port to pass a health check | Cron job | Yes, differently | A scheduled HTTP call to your app, not a separate command | Managed Postgres | Yes | One private database per project on your server | Pull request previews | Not included | Use a staging project | Blueprint-style infrastructure file | Not included | Projects are created by command or API | Persistent disk | Not included | Use the database or object storage | ## Choose Render if - You run background workers or cron jobs that execute a command, not an HTTP call. - You rely on a persistent disk attached to a service. - You want previews for every pull request. ## Choose Stackap if - Your services are web apps, APIs and static sites. - You would rather pay for a server than for each service. - You want backups you can restore and verify, going to a bucket you own. ## What the money looks like Render prices each service and database by plan, and those prices change, so read its pricing page. On Stackap every project on the machine shares one server price, so the more small services you run, the better the arithmetic looks. That advantage reverses if one service needs more than the machine has. Check your heaviest service against four cores and eight gigabytes first. ## Early-access scope - No background workers and no command-style cron jobs. - No persistent disk and no previews. - Everything shares one machine, so a busy project can slow its neighbours. - Stackap is early access, invite-only. ## Questions **Q: How do I turn a cron job into something Stackap can run?** Expose its work as an endpoint on your app, protected by a secret, and schedule a call to that path. The schedule is in UTC. **Q: Can I keep Render for the database only?** Yes, and move the app. The app would then reach its database across the internet from Germany, which adds latency to every query, so measure before committing to that split. **Q: Does a static site cost extra?** No. It runs as a tiny nginx container on the same server. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/supabase-alternative/ Compare # A Supabase alternative, and what carries over Stackap is an alternative to Supabase for the data side only: your tables and rows, the generated data API and file storage carry over, but sign-in, realtime and edge functions do not. ## The short answer Supabase is several products behind one dashboard, and the question for any move is which of them your app uses. A project that uses it as a Postgres database with a generated API and some file storage can move. A project built around its sign-in and realtime features cannot, whatever the destination. Stackap's data side is built from the same open-source parts, so the change is mostly in who runs them. The checklist below is ordered by how often each feature blocks a move. Do the work in a fixed order. Settle sign-in first, because it decides everything. Then inventory functions and triggers, then copy the data into a staging project, then move files, then compare, and only then plan a cutover. Each step before the last is cheap to undo. ## Side by side Supabase feature | On Stackap | Effect on a move | Sign-in and user management | Not included | Blocks the move until the app brings its own | Row-level security policies tied to users | Postgres supports them; the tie to sign-in is gone | Rewrite policies that read the signed-in user | Realtime subscriptions | Not included | Blocks, or replace with polling | Edge functions | Not included | Move the logic into the app | Generated REST API | Yes, same engine | Client code keeps working for data calls | File storage | Yes, same service on R2 | Copy objects, rewrite stored URLs | Database functions, triggers and views | Postgres, yes; copied separately | Extract and apply them by hand | Point-in-time recovery | Not included | Daily backups instead | Dashboard table editor | A table browser per project | Similar, simpler | ## Choose Supabase if - Sign-in or realtime is part of how your app works. - You want someone else to operate your database and offer point-in-time recovery. - You rely on database features that the hosted product wraps in a dashboard. ## Choose Stackap if - You use Postgres, the generated API and storage, and bring your own authentication. - You want your data, files and app on one server, with one backup system. - You want to hold the encryption key and the backup bucket yourself. ## What the money looks like Supabase prices by plan and usage, which changes, so check its pricing page. On Stackap the database costs the share of a server you already rent. The saving is smaller than on hosting, because a database is cheap to run and expensive to be responsible for. On Stackap that responsibility is yours, with daily backups and no point-in-time recovery. ## Early-access scope - No sign-in, realtime or edge functions, and none is on a published schedule. - The migration copies tables and rows. In one inventory, the great majority of database functions lived only in the live database and had to be extracted by hand. - Backups are daily, so recovery can lose up to a day. - The data API has been run for one project, not exercised across every feature of the client library. ## Questions **Q: What is the best alternative to Supabase?** If you use Supabase mainly as Postgres with an API and storage, running your own on Stackap is the closest match. If you use its sign-in or realtime, no alternative here replaces them. **Q: Can I keep Supabase for sign-in only?** Technically yes, but your policies and data would then live in two systems. We do not recommend splitting that way without a plan. **Q: Does the client library still work?** For data and storage calls, in the one project tested. Calls to the sign-in service will not. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/supabase-vs-stackap/ Compare # Supabase vs Stackap Supabase is a hosted backend built around Postgres, with sign-in, storage and realtime; Stackap gives each project its own Postgres and storage on a server you own, but not sign-in or realtime. ## The short answer If you came to Supabase for a Postgres database with a generated API and file storage, Stackap offers the same shape on your own hardware. If you came for sign-in, row-level policies tied to users, or realtime subscriptions, Stackap does not have them yet, and that settles the question for those apps. This comparison is narrower than the Vercel one, because Supabase and Stackap overlap only on the data side. Stackap also deploys the application, which Supabase does not. On the data side the overlap is built from the same open-source parts. The generated REST API is served by PostgREST, which is the component the hosted product's own API is also built on, and file storage uses the open-source storage service pointed at an R2 bucket. That is why a real app's data calls kept working when its tables were copied across, and also why the gaps are exactly the hosted product's own extras: the pieces around the database, not the database itself. ## Side by side | Supabase | Stackap | Postgres database | Yes, hosted | Yes, one private database and role per project | Generated REST API | Yes | Yes, a Supabase-compatible data API per project | Sign-in and user management | Yes | Not included | Realtime subscriptions | Yes | Not included | File storage | Yes | Yes, using the open-source storage service on R2 | Serverless functions | Yes | Not included | Hosts your application | No | Yes, with git deploys | Backups | Provided by the service | Daily, encrypted, restore-verified, to your own bucket | Browse and edit tables | Yes, in a dashboard | Yes, a table browser per project | Who runs it | Supabase | You | ## Choose Supabase if - Your app uses its sign-in service or realtime features. - You want a managed database with point-in-time recovery and a team that operates it. - You prefer not to carry operational responsibility for data. ## Choose Stackap if - Your app uses Postgres and the data API but brings its own authentication. - You want the database, the files and the application on one server with one backup system. - You want to own the encryption key and the backup bucket. ## What the money looks like Supabase prices by plan and usage; check its pricing page for the current figures. On Stackap the database costs whatever room it takes on a server you already pay for. The data-side saving is real but smaller than the hosting saving, because a database is cheap to run and expensive to be responsible for. That responsibility moves to you, with daily backups and no point-in-time recovery yet. ## Early-access scope - No sign-in, no realtime, no serverless functions. - Not every function, trigger and view in a database moves automatically; the migration tool copies tables and rows, so database functions must be carried over separately. - Daily backups with no point-in-time recovery. A restore can lose up to a day. - Compatibility with the data API client library has been tested on a real app's tables, not on every feature of the library. ## Questions **Q: Will my supabase-js code keep working?** Data calls can, because Stackap exposes a compatible API for a project's database. Calls to the sign-in service will not. **Q: Can I migrate gradually?** Yes, but a database is the hardest thing to move gradually, so plan a single cutover with a final copy and a rollback path. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/vercel-alternative/ Compare # A Vercel alternative, and what to check before you move Stackap is an alternative to Vercel for apps that are a Next.js or static front end plus a database, run on one server you own, but it does not replace Vercel's previews, edge network or serverless functions. ## The short answer People start looking for a Vercel alternative for one of a few reasons: the bill has grown with traffic, the app needs a database and storage close by, or they would rather own where it runs. Those are the cases Stackap was built for. The honest first step is not a migration. It is an audit of which Vercel features your project actually touches, because the ones Stackap lacks are exactly the ones you may be using without thinking about them. The table walks through them. ## Side by side What you use | On Stackap | What to do | Push-to-deploy from Git | Yes, to Stackap's own git | Add the Stackap remote and push | Preview deployments | Not included | Use a second project as a staging copy | Serverless and edge functions | Not included | Run the logic as a Node app or inside Next.js on a container | Global edge cache | Not included | Accept one location, or put a CDN in front yourself | Cron jobs | Yes, UTC, imports vercel.json | Import, then stop the old ones | Environment variables | Yes, encrypted | Set each one; public ones before the build | Custom domains and HTTPS | Yes | Create the A record yourself | Web analytics and speed insights | Not included | Stackap shows server-side load time only | Firewall and DDoS protection | Not included | Put a protective proxy in front if you need one | Image optimization | To be verified | Test your own pages before relying on it | ## Choose Vercel if - You use previews on every pull request as part of how your team reviews work. - Your visitors are worldwide and an edge cache is carrying real weight. - You depend on analytics, a firewall or other platform products that sit around hosting. - You have no one to answer an alert at night. ## Choose Stackap if - Your project is conventional: one app, one database, a few scheduled jobs. - The platform bill is the problem you want to solve and traffic fits on a four-core machine. - You want the database, the files and the app on a server you can inspect. - You want your coding agent to deploy with commands and read logs itself. ## What the money looks like Vercel bills by plan and by usage, and the meters change, so read its pricing page before comparing. Stackap's cost follows the server you choose, not your traffic. The cost that is easy to forget is your own time. Someone updates the server, watches alerts and decides what to do when something breaks. That is cheap with one app and a comfortable terminal user, and expensive if nobody wants the job. ## Early-access scope - No previews, no edge network and no serverless functions, which are the three most-used things people lose. - A single server in Germany is slower for distant visitors. - Image optimization on Stackap has not been tested. - Stackap is invite-only, so you cannot start tonight. ## Questions **Q: What is the best alternative to Vercel?** It depends on what you use. For a Next.js or static app with a database and no need for previews or an edge network, Stackap on one server is the cheapest. If you need previews and global delivery, a hosted platform is the better choice. **Q: Is there a free alternative to Vercel?** Stackap is not free. Early access terms are arranged with each team; see pricing. **Q: Do I have to leave Vercel entirely?** No. Many setups keep the front end where it is and move only the database and storage. Moving the app is separate. **Q: Is a move reversible?** Yes, while the old project still exists. Going back is changing one DNS record, so keep it until the new one has carried real traffic. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/vercel-and-supabase-alternative/ Compare # A Vercel and Supabase alternative Stackap replaces the combination of a hosting platform and a hosted database with one server you own, doing git deploys, HTTPS, per-project Postgres, file storage, cron jobs and backups together. ## The short answer Many apps built with a coding agent end up on exactly two services: one that hosts the front end and serverless functions, and one that provides the Postgres database, file storage and sign-in. Two accounts, two dashboards, two sets of keys, and a bill from each. Stackap covers the deploy, database, storage, domain and scheduling parts of that pair on a single server, so there is one account, one set of keys and one bill, which is the cost of the server. It does not cover everything the two products offer. The table says where it stops. ## Side by side | Vercel | Supabase | Stackap | Git-based deploys | Yes, from connected Git hosts | Not its job | Yes, from Stackap's own git | Preview deployments per branch | Yes | Not its job | Not included | Global edge network | Yes | No | Not included, one server today | Managed Postgres | Through partners | Yes, its core product | Yes, one private database per project | Sign-in and user management | Not its job | Yes | Not included | File storage | Yes | Yes | Yes, S3-compatible on R2 | Realtime subscriptions | Not its job | Yes | Not included | Scheduled jobs | Yes | Via the database or functions | Yes, with vercel.json import | You run the infrastructure | No, hosted | No, hosted | Yes, you own the server | Pricing model | Usage-metered plans | Usage-metered plans | The price of a server plus a few dollars | ## Choose Vercel and Supabase if - You need previews on every branch, a global edge network, or a team workflow around them. - Your app depends on Supabase sign-in or realtime features, which Stackap does not provide. - Nobody on your team wants to own a server, however automated, and your hosted bill is small enough not to matter. - You need compliance certifications today; they are not part of early access. ## Choose Stackap if - Your bill has grown into real money and your apps are conventional: a web app, a Postgres database, some files, a few scheduled jobs. - You want to own where the code and the data live, and to move them with a command. - You run several apps and want them on one box with isolation between projects. - A coding agent does your deploys, and you want the whole path to be commands it can run. ## What the money looks like On a hosted platform the bill is a set of meters that follows your usage. On Stackap, capacity is a server you choose, so more traffic makes the machine busier and not the invoice larger. The trade is that you operate the server: someone applies updates and answers alerts, and Stackap automates the routine parts. For a team with several apps and someone comfortable at a terminal, that is a small, steady task. ## Early-access scope - Stackap has no sign-in service. An app that uses a hosted sign-in product cannot move until it brings its own. - Early access runs on one server. A full rebuild drill on a fresh machine is on the roadmap. - Backups are daily with no point-in-time recovery. - Stackap is in invite-only early access, and independent security review and certifications are not part of it. ## Questions **Q: Can I use Stackap alongside Vercel or Supabase?** Yes. Nothing requires an all-or-nothing move. You can move the database and storage first and keep the front end where it is, or the reverse. **Q: Does Stackap read my Supabase client code?** It exposes a Supabase-compatible data API for a project's database, so code written against that client library can keep working. Sign-in is the part that is not compatible. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/compare/vercel-vs-stackap/ Compare # Vercel vs Stackap Vercel is a hosted deployment platform that runs your app on its infrastructure; Stackap is software that runs on a server you own and gives you the same push-to-deploy loop on it. ## The short answer The difference is who runs the machines. With Vercel, they do, and you get a global network, per-branch previews and a large ecosystem in exchange for usage-based pricing. With Stackap, you do, on one server, and you get a fixed and very low cost in exchange for owning the operations. For an app that is a conventional Next.js or static site with a database behind it, both will serve it. The question is which trade you want. ## Side by side | Vercel | Stackap | Who runs the servers | Vercel | You, on a server you rent | Deploy trigger | Push to a connected Git host | Push to Stackap's own git, or stackap deploy | Branch previews | Yes | Not included | Global edge delivery | Yes | Not included; one server in Germany today | Serverless and edge functions | Yes | Not included; apps run as ordinary containers | Next.js support | First-party, by the same company | Generated Dockerfile; one large site measured at 96 s build | Rollback | Yes | Yes, one command to the previous deployment | Cost shape | Plans plus usage | The cost of the server | Moves with you | Tied to the platform's features | Standard containers and Postgres | ## Choose Vercel if - Visitors are spread across the world and latency matters to you. - Your team relies on preview URLs and review workflows for every branch. - You use platform-specific features such as edge middleware or its image service at scale. - You would rather pay than operate. ## Choose Stackap if - Your hosting bill is the thing you want to change and your traffic fits on one machine. One test showed about 700 requests per second from a single 4-CPU server on real pages. - You want your app, its database and its files in one place that you control. - You are happy to run tests before pushing, since there is no built-in test gate. - You want rollback, health-checked deploys and HTTPS without assembling them, and one place for the app, its database and its files. ## What the money looks like Vercel is billed by plan and usage, and the details change, so check its pricing page for the current numbers. Stackap's cost follows the server you choose, not your traffic. Do the sum with your own bill, not ours. The difference is largest when a bill is large and a team has someone comfortable with a terminal, and smallest when an app sits comfortably inside a free plan. ## Early-access scope - No preview deployments, no edge network, no serverless functions: the three things people most often miss when leaving a hosted platform. - Delivery from a single server in Germany is slower for distant visitors, and nothing in front of it caches the pages. - Stackap is invite-only early access, so you cannot simply sign up. ## Questions **Q: Can Stackap run Next.js apps that use server rendering?** Yes, as a long-running container. Features that rely on a vendor's edge network will not behave the same. **Q: Is Stackap a drop-in replacement?** No. It covers the common path for conventional apps and is open about what it leaves out. Facts about other products on this page were last checked on 2026-10-03. Check their own pages before you decide. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/ Deploy guides # Deploy guides Step-by-step guides for putting a specific kind of app on Stackap, from a local repository to a live HTTPS domain. Step-by-step guides for putting a specific kind of app on Stackap, from a local repository to a live HTTPS domain. Each guide lists what to check before pushing, what to watch while it builds, and how the common failures look, so a first deploy does not need a second attempt. ## Pages in this section - Deploy a Next.js app: How to deploy a Next.js app to a server you own: git push, public build variables, a custom domain and a one-command rollback. Step by step. - Deploy a React app: Step by step: deploy a React single-page app to Stackap, the router and base-path settings that matter, and how to tell Vite from Create React App. - Deploy a Vite app: Step by step: deploy a Vite or Create React App single-page app to Stackap, with the index.html fallback, build-time variables and a custom domain. - Deploy a Node.js API: Step by step: deploy a Node.js API with a start script to Stackap, with the PORT contract, a health path, secrets and a database. - Deploy an Astro site: Step by step: deploy a static Astro site to Stackap, with real 404 pages, build-time image handling and the server-adapter caveat. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/deploy-astro/ Deploy guides # How to deploy an Astro site on Stackap To deploy a static Astro site on Stackap you remove any server adapter, push the repository, and the server builds the site and serves it from nginx with real 404 pages. ## Before you start This guide is for content sites built with Astro in its default static mode: blogs, documentation, marketing sites. It is honest about one thing up front: no Astro site has been shipped on Stackap by its builders yet, so this guide rests on the generic static-site path, which has real build tests. The deciding question is whether your site needs a server at request time. If it does not, this guide applies. ## Check these in your Astro project - astro is a dependency and the build script produces the finished site. - No @astrojs/node, @astrojs/vercel or @astrojs/netlify adapter is installed. Any of them moves the project off the static path. - The output mode is static, which is the default. - A custom 404 page exists if you want one. - Images are processed at build time, not requested through a runtime image service. ## What to watch while it builds In the build log, look for the line that names the detected type. It should say a static site (Astro). If it names a Node app or refuses the build, an adapter is still in your dependencies. After it goes live, request a path that does not exist. A static site returns a real 404 status, which matters for search engines. ## When it does not go live **Build refused with a reason**: The project is not recognized. Check for a server adapter and for a missing build script. **Detected as a Node app and fails to start**: An adapter is present and there is a start script. Remove the adapter for the static path. **Links break under a sub-path**: The site was built with a base that does not match the domain. **Images missing**: They were referenced from a runtime service. Move them into the build or into object storage. ## Steps - Get access, a token and an SSH key. Request an invitation at the contact page. You receive the server's API address and a token. Pushing uses SSH, so the public key you push with must also be registered with your organization, which an owner token can do through POST /v1/ssh-keys, or the operator can do for you. Log in and create the project. Log in once, then create a project for the app. $ stackap login --url https://api. --token-stdin $ stackap create my-astro-site --name "My Astro Site" - Prepare the repository. Remove the adapter if it is only there for local convenience, run the build once locally to confirm it finishes, and add the project's Stackap remote. Set environment variables. A static site has no runtime, so variables matter only at build time and end up in the output. Set what the build needs and nothing secret. $ stackap env set my-astro-site PUBLIC_SITE_URL --stdin Push. Deploy. The image builds your site and copies it into nginx. $ stackap deploy my-astro-site $ stackap logs my-astro-site --source build Point your domain at it. Create the DNS record, then attach the hostname. $ stackap domains add my-astro-site www.example.com ## Early-access scope - Astro-specific features have not been exercised on Stackap by us, so treat them as unverified. - No server-side rendering or on-demand routes through this path. - No CDN, so far-away visitors see more latency. ## Questions **Q: Why not use an Astro adapter?** An adapter produces server code, which the static path does not run. Astro with an adapter would need to run as a Node app, which we have not tested. **Q: Will it get real 404s?** Yes. Static-site frameworks are served with true 404 responses. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/deploy-nextjs/ Deploy guides # How to deploy a Next.js app on Stackap To deploy a Next.js app on Stackap you create a project, set your environment variables, and push; the server generates the Dockerfile, builds, checks health and goes live over HTTPS. ## Before you start This guide takes a Next.js app from a local repository to a live domain. It assumes you already have a Stackap server and an access token, which today means being invited, because Stackap is in early access. The shortest version is two commands once the project exists: set variables, then deploy. The rest of this page is what to check so the first build succeeds. ## Check these in your Next.js project - package.json lists next, and has build and start scripts. - A lockfile is committed. A stale lockfile makes npm ci fail, so run an install and commit the result. - Every variable the browser needs starts with NEXT_PUBLIC_. They are baked in during the build. - No page needs a real secret while the site is statically generated, because the build sees placeholders for everything that is not public. - If you use remote images, the hosts are listed in the Next.js config. ## What to watch while it builds A large Next.js build is the heaviest thing the server does. One 31,592-page site takes about 96 seconds and peaks near 2.8 GB of memory, so expect the build log, not the site, to be the slow part. Read the build log first with --source build. If the build passes and the app still does not go live, switch to --source runtime, which shows what the container printed when it tried to start. ## When it does not go live **Build fails at install**: Almost always a stale lockfile. Regenerate it locally, commit, and push again. **Build passes, health check fails**: The app did not answer on the expected port or path. Check the runtime log for a crash and confirm the app reads PORT. **Pages show placeholder data**: A page read a non-public variable at build time and saw the placeholder. Fetch that data at request time instead. **Images do not load**: The remote image host is missing from the Next.js config. ## Steps - Get access, a token and an SSH key. Ask for an invitation at the contact page. You will be given the API address of the server and a token that is shown once. Keep it in a password manager. Pushing uses SSH, so the public key you push with must also be registered with your organization, which an owner token can do through POST /v1/ssh-keys, or the operator can do for you. Log in and create the project. Log in once, then create a project for the app. $ stackap login --url https://api. --token-stdin $ stackap create my-next-app --name "My Next App" - Prepare the repository. Add the project's Stackap remote next to your existing one, and make sure the branch you intend to ship is the project's production branch. Only that branch triggers a build. Set environment variables. Set public variables first, because they are fixed at build time, then secrets. Each value is read from standard input so it never appears in a shell history. $ stackap env set my-next-app NEXT_PUBLIC_SITE_URL --stdin $ stackap env set my-next-app SESSION_SECRET --stdin Push. Deploy. Stackap generates the Dockerfile, builds, starts the container beside the old one, checks health, then switches. $ stackap deploy my-next-app $ stackap logs my-next-app --source build Point your domain at it. Add the hostname. Stackap checks that DNS points at the server before it issues a certificate, so create the record at your DNS provider first. $ stackap domains add my-next-app www.example.com ## Early-access scope - No preview deployments, so test a branch locally or on a second project before it reaches production. - Non-public variables are placeholders at build time, so build-time data fetching with secrets does not work. - The domain step needs a DNS edit that you make by hand at your DNS provider. ## Questions **Q: Can I self-host a Next.js app?** Yes. Stackap generates a Dockerfile, builds on your server and serves the app as a small non-root container with automatic HTTPS. A 31,592-page site builds in about 96 seconds. **Q: Can I deploy a Next.js app without Vercel?** Yes. Nothing here uses Vercel or GitHub. You push to the project's own git remote on your Stackap server. **Q: Can I roll back?** Yes. stackap rollback my-next-app returns to the previous deployment after checking it is healthy. See rollbacks. **Q: Do I need Vercel or GitHub?** No. Stackap hosts the git remote itself. You can keep GitHub for your own history. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/deploy-nodejs/ Deploy guides # How to deploy a Node.js API on Stackap To deploy a Node.js API on Stackap you make sure it has a start script and listens on the PORT it is given, set a health path if needed, and push. ## Before you start This guide is for a server that stays running: an API, a small web app, anything that answers HTTP. It is the most flexible path and also the one with the most things that can go wrong, because your own code is in charge of starting correctly. If your app has its own Dockerfile, Stackap uses it and most of the checks below do not apply. ## Check these in your Node.js project - package.json has a start script that runs the server and does not exit. - The server listens on process.env.PORT, not a fixed number. - There is a route that returns a success status when the app is ready, such as /healthz. - Secrets are read from environment variables, never from files in the repository. - The app does not write data to its own disk and expect to find it after a deploy. ## What to watch while it builds The first thing to read is the runtime log. A crash on start, a missing variable or a port mismatch shows up there within seconds of the container launching. An API with no page at the root will fail the default health check. This was reproduced with a toy API and fixed by setting port 8080 and the path /healthz. ## When it does not go live **Health check never passes**: The app is listening on a hard-coded port, or the health path returns an error. Read the port from PORT and add a health route. **Build refused, no start script**: Add a start script, or add a Dockerfile. **Data disappears after a deploy**: It was written to the container's disk. Use the project's Postgres database or object storage. **Cannot reach the database**: Check the connection string you set. Each project has its own database role that can reach only its own database. ## Steps - Get access, a token and an SSH key. Request an invitation at the contact page. You receive an API address and a one-time token. Pushing uses SSH, so the public key you push with must also be registered with your organization, which an owner token can do through POST /v1/ssh-keys, or the operator can do for you. Log in and create the project. Log in once, then create a project for the app. $ stackap login --url https://api. --token-stdin $ stackap create my-api --name "My API" - Prepare the repository. Add the project's Stackap remote. If the app serves on a port or health path other than the defaults, the project owner sets them once through the settings API (PUT /v1/projects/:slug/settings), for example port 8080 and /healthz. Set environment variables. Add secrets such as a database URL one at a time from standard input. $ stackap env set my-api DATABASE_URL --stdin $ stackap env set my-api API_KEY --stdin Push. Deploy and watch the runtime log, since a Node app can build fine and still fail to start. $ stackap deploy my-api $ stackap logs my-api --source runtime --limit 100 Point your domain at it. Create the DNS record, then attach the hostname. $ stackap domains add my-api api.example.com ## Early-access scope - The app must serve HTTP; a background worker without a port cannot pass a health check yet. - No persistent container disk, and no sidecar processes. - Python and other runtimes are not supported without your own Dockerfile. ## Questions **Q: Can I run scheduled jobs?** Yes. Stackap runs cron entries per project, and can import them from a vercel.json with stackap cron import. **Q: How do I get a database?** Each project can have its own private Postgres database, created and backed up by the platform. See backups. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/deploy-react/ Deploy guides # How to deploy a React app on Stackap To deploy a React app on Stackap you push a repository whose build script produces an index.html; the server builds it, serves it with a router-friendly fallback, and puts it on HTTPS. ## Before you start This guide is about the questions React developers actually hit, which are about routing and public values and not about the server. If your React app is Next.js, use the Next.js guide instead, because it has a server and different rules. The two cases below are Vite and Create React App. They build differently but are served identically. ## Check these in your React project - The build script writes an index.html into dist (Vite) or build (Create React App). - The router uses the root of the domain. If you configured a basename, remove it. - Every value your code reads is prefixed VITE_ or REACT_APP_ and none is secret. - API calls use an absolute URL, because the static app has no backend of its own. - You are not relying on server components or server rendering. ## What to watch while it builds The build log should say Stackap generated an image for a single-page app and name vite or react-scripts. If it names a Node app instead, your package.json has a start script and no recognized build tool in dependencies. After it is live, open a nested route directly and refresh. If the page loads, the fallback to index.html is working and your router can take over. ## When it does not go live **A refresh on a route shows a blank page**: The router has a basename that does not match the domain, so it renders nothing. Remove it. **The build stops saying no index.html was found**: Your build writes to a folder that is not on the searched list. Change the output folder or bring a Dockerfile. **Values are undefined at runtime**: They lacked the public prefix, so the bundler left them out. **The app shows old content after a deploy**: The browser kept the previous JavaScript. Files have hashed names, so a hard refresh clears it; the HTML itself is not cached. ## Steps - Get access, a token and an SSH key. Ask for an invitation at the contact page. You receive the API address and a token shown once. Pushing uses SSH, so the public key you push with must also be registered with your organization, which an owner token can do through POST /v1/ssh-keys, or the operator can do for you. Log in and create the project. Log in once, then create a project for the app. $ stackap login --url https://api. --token-stdin $ stackap create my-react-app --name "My React App" - Prepare the repository. Run npm run build locally first and open the output folder. Seeing an index.html there is the single best predictor that the server build will pass. Set environment variables. Set the public values that the build reads. They are written into the JavaScript files, so treat each as published. $ stackap env set my-react-app VITE_API_URL --stdin Push. Deploy and watch the build log for the line naming the detected type. $ stackap deploy my-react-app $ stackap logs my-react-app --source build Point your domain at it. Create the A record at your DNS provider, then attach the hostname. $ stackap domains add my-react-app app.example.com ## Early-access scope - Server components and server rendering are not served by this path. - Unknown URLs return the app with a 200 status, not a real 404. - Create React App projects build, but it is an old tool, so a new project should use Vite. ## Questions **Q: Can I deploy a React Router framework-mode app?** Only if it builds to static files. If it renders on a server, it is a different case and is not detected. **Q: Do I need a backend?** Only if your app needs one. A static app can call any API, including a separate Node project on Stackap. Last updated 2026-10-03. --- Source: https://www.stackap.com/deploy/deploy-vite/ Deploy guides # How to deploy a Vite or React app on Stackap To deploy a Vite or React single-page app on Stackap you push the repository; the server builds it with your build script and serves the output from nginx with an index.html fallback. ## Before you start This guide is for single-page apps whose output is a folder of static files: Vite, Create React App, Vue CLI and Parcel projects. Nothing runs on the server after the build, so there is no port to configure and no process to keep alive. Because the output is static, any value your code reads from the environment is fixed into the files at build time and is readable by every visitor. ## Check these in your Vite project - package.json has a build script and lists vite, react-scripts, @vue/cli-service or parcel. - No server adapter or server-rendering framework is in use. Those are a different case. - Every variable the app reads uses your bundler's public prefix, such as VITE_, and holds nothing secret. - A lockfile is committed. - The app calls its API at an absolute URL, because a static app has no backend of its own. ## What to watch while it builds A static build is usually the quickest thing Stackap does, since there is no server to start and nothing to warm up. We have not benchmarked Vite builds specifically, so read the build log for your own timings. Once live, open a deep link such as /settings directly in the browser. If it loads the app and not a 404, the index.html fallback is working. ## When it does not go live **Build fails, command not found**: The build script calls a tool that is only a dev dependency in the wrong group. Make sure the build tools install in the image. **Blank page after deploy**: The app was built with a base path that does not match the domain. Set the base to /. **Requests to the API fail**: The app calls a relative URL that no longer exists on this host. Use the absolute address of your backend. **Refreshing a route returns 404**: This should not happen on the single-page path. If it does, the project was detected as a different type; check the build log's detection line. ## Steps - Get access, a token and an SSH key. Request an invitation at the contact page. You receive the server's API address and a one-time token. Pushing uses SSH, so the public key you push with must also be registered with your organization, which an owner token can do through POST /v1/ssh-keys, or the operator can do for you. Log in and create the project. Log in once, then create a project for the app. $ stackap login --url https://api. --token-stdin $ stackap create my-vite-app --name "My Vite App" - Prepare the repository. Add the project's Stackap remote and make sure your production branch is the one you push. If your app lives in a subfolder of a monorepo, move it to the repository root first, because monorepo layouts are untested. Set environment variables. Set only public values. They are compiled into the files, so treat each one as published. $ stackap env set my-vite-app VITE_API_URL --stdin Push. Deploy. Stackap generates a two-stage image: your build, then nginx. $ stackap deploy my-vite-app $ stackap logs my-vite-app --source build Point your domain at it. Create the DNS record at your provider, then add the hostname so Stackap can issue a certificate. $ stackap domains add my-vite-app app.example.com ## Early-access scope - Static output only, so server-side rendering is out of scope. - Unknown URLs return the app shell with a 200 status, not a real 404. - Monorepo layouts are untested. ## Questions **Q: Will my environment variables stay secret?** No. In a static app every variable is compiled into files the browser downloads. Never put a secret in one. **Q: Can I host the API on Stackap too?** Yes, as a separate Node project. See deploying a Node.js app. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/ Developers # Developers Reference material for people and agents who operate Stackap: the command-line tool, the HTTP routes and the plain-text site summaries. Reference material for people and agents who operate Stackap: the command-line tool, the HTTP routes and the plain-text site summaries. These pages describe what exists today. The API describes itself at a public address, and request and response body schemas are the part still to come. ## Pages in this section - Documentation: An index of Stackap documentation by task: shipping an app, operating it and moving an existing one, with what does not exist yet. - API reference: Every Stackap HTTP route that exists today, with its request body, what it returns, who may call it and how errors look. - CLI reference: Every command in the Stackap command-line tool, with what it does, how it takes secrets, how it signals failure, and what is not built yet. - Agent documentation: Plain-text Stackap documentation for coding agents: the canonical definition, llms.txt files, authentication, and the HTTP routes that exist today. - Changelog: What has shipped in Stackap, by date, written from the verified state of the platform, with nothing listed that is only planned. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/agent-docs/ Developers # Documentation for agents Stackap is an application platform that provides deployment, runtime, PostgreSQL, storage, domains, HTTPS, cron jobs, secrets, logs, metrics, monitoring, backups and rollback through an agent-operable control plane. ## Read this site as text - /llms.txt: a short summary and an index of every page. - /llms-full.txt: the full text of the site as Markdown. - /sitemap.xml: every page and when it last changed. These files are generated from the same pages people read, so the machine-readable and human versions cannot drift apart. If you find a difference, the page is wrong, and we want to know at hi@stackap.com. ## The API describes itself GET /v1/capabilities and GET /v1/openapi.json need no token. An agent that knows nothing about Stackap can call them to learn every route, the scope each one needs, the error codes and the error shape. They are generated from the server's own permission table, so they cannot drift from what the server enforces. ## Authentication Every API call carries Authorization: Bearer . A token belongs to exactly one organization, and the organization is taken from the token and from nowhere else: an organization named in a request body, header or query string has no effect. A request for a resource in another organization returns the same response as a request for one that does not exist. ## Routes that exist today Route | What it does | GET /v1/status | Overall health and monitor checks. | GET, POST /v1/projects | List or create projects. | PUT /v1/projects/:slug/settings | Set the port and health path (owner). | PUT /v1/projects/:slug/scale | Run 1 to 8 copies of a project (platform admin). | GET /v1/projects/:slug/deployments, POST …/rollback | List deployments, roll back. | GET /v1/projects/:slug/logs?source=build|runtime | Read logs. | GET, PUT, DELETE /v1/projects/:slug/env/:key | Manage environment variables. | GET, POST /v1/projects/:slug/domains | List or attach hostnames. | GET, POST /v1/projects/:slug/backups, POST …/restore | List or take backups; restore into a new database. | GET /v1/projects/:slug/metrics | Load-time and request metrics. | POST /v1/orgs | Create an organization (platform admin). | All routes are under /v1. This is a map, not a full reference: request and response shapes are not yet documented route by route, and until they are, the command-line tool is the better-specified way in. ## A prompt you can hand to an agent This is the prompt used on the get-started page. It points the agent at the plain-text docs and the public API description, states the rules, and lists the steps. You are going to deploy an application to Stackap, a platform you operate through its command-line tool and HTTP API. First read these, in order: 1. https://www.stackap.com/llms.txt 2. https://api.stackap.com/v1/capabilities (every route, scope and error code; no token needed) Rules: - Never put a secret on a command line. Pass secrets on standard input (--stdin). - If a deploy does not go live, read the build log and then the runtime log before changing any code. - Ask me before deleting anything and before pointing a production domain at the server. - If a call answers approval_required, tell me, wait for my decision, then repeat the identical request. Task: 1. Log in: stackap login --url https://api.stackap.com --token-stdin (I will give you the token.) 2. Create a project: stackap create my-app --name "My App" 3. Set each environment variable: stackap env set my-app KEY --stdin 4. Deploy: stackap deploy my-app 5. Read the result: stackap logs my-app --source build 6. Tell me the live address and what you checked. ## Operating rules for an agent - Read the log before changing code. logs --source build and --source runtime say why a deploy did not go live. - Treat rollback as code-only. It does not undo data. - Never put a secret on a command line. Use --stdin. - Ask a person before anything destructive, and before pointing a production domain. ## Early-access scope - The machine-readable description lists routes, scopes and errors but not request and response body schemas yet. - No dedicated tool-protocol server. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/api/ Developers # API reference The Stackap HTTP API exposes every operation the command-line tool and the dashboard perform, authenticated by a bearer token that belongs to exactly one organization. ## Conventions Every route is under /v1, sends and receives JSON, and takes Authorization: Bearer . A token belongs to one organization, and the organization comes from the token alone. A resource in another organization returns the same 404 as one that does not exist. Errors are JSON with an error field, and some also carry a stable code. Roles are owner, member and platform admin; routes marked as operator-only return 403 to anyone else. ## Projects Route | What it does | POST /v1/projects | Body {slug, name}. Creates a project and its git repository. Returns the project. Refused with 403 at the organization's project limit (default 10). | GET /v1/projects, GET /v1/projects/:slug | List projects, or read one. | PUT /v1/projects/:slug/settings | Body {port?, health_path?}; null resets a value. Applies from the next deploy. Owner only. | ## Deployments Route | What it does | GET /v1/projects/:slug/deployments | Up to 100 rows with id, number, status, build_id, image_ref, created_at, activated_at, retired_at and rolled_back_from. | GET /v1/projects/:slug/builds, GET /v1/builds/:id, GET /v1/builds/:id/logs | Builds, one build, and the log of any build by id. | POST /v1/projects/:slug/rollback | Returns {status, deployment}. 502 if the previous deployment is unhealthy, 409 if there is nothing to roll back to. | PUT /v1/projects/:slug/scale | Body {replicas}, 1 to 8. Platform admin only. | ## Variables and domains Route | What it does | GET /v1/projects/:slug/env | Keys and a mask, never values. System variables are flagged. | PUT /v1/projects/:slug/env/:key | Body {value}. 204. Refuses a system key with 409. DELETE removes one. | POST /v1/projects/:slug/domains | Body {hostname}. 201 with dns_status, ssl_status and an instructions object giving the A record to create. | GET /v1/projects/:slug/domains, DELETE …/domains/:hostname | List with refreshed status; detach. | ## Cron Route | What it does | GET /v1/projects/:slug/cron | Jobs with their last status and last run time. | PUT /v1/projects/:slug/cron/:name | Body {schedule, path, enabled?}. UTC, five fields; the path starts with a slash. | POST /v1/projects/:slug/cron/import | Body {crons: [{path, schedule}]} in vercel.json format. Returns {imported}. | GET /v1/projects/:slug/cron/:name/runs | Run history. | ## Data, backups and metrics Route | What it does | GET, POST /v1/projects/:slug/database | Read or provision the project's database. Credentials are never returned. | GET /v1/projects/:slug/data/tables and …/tables/:schema/:table | Table browser reads with limit, offset, sort, dir and q. POST …/rows with {values} and DELETE …/rows with {key} write; owner only. | POST, GET /v1/projects/:slug/backups | Take a backup (201, {id, status}) or list the most recent 100. | POST /v1/projects/:slug/restore | Body {backup_id?}. Restores into a new database and returns its name. The live database is never modified. | POST /v1/backups/:id/verify | Restore a backup into a scratch database and compare row counts. | GET /v1/projects/:slug/metrics?range=1h|24h|7d, …/timeline | Load-time metrics and a timeline of what changed. | GET /v1/projects/:slug/logs?source=build|runtime&limit=N | Logs, 1 to 5000 lines. | ## Access and organizations Route | What it does | POST, GET /v1/api-tokens, DELETE /v1/api-tokens/:id | Body {name, role?, scopes?, expires_in_days?}. Roles are owner and member. GET /v1/capabilities lists the scope names. | POST, GET /v1/ssh-keys, DELETE /v1/ssh-keys/:id | Register the public key you push with. Body {name, public_key}. | GET /v1/me, /v1/overview, /v1/activity | Who you are, a dashboard summary, and recent changes in your organization. Values are never included. | POST, GET /v1/orgs | Platform admin only. Body {slug, name, max_projects?}; the reply includes an owner token shown once. POST …/orgs/:slug/disable and …/enable suspend and restore one. | GET /v1/approvals, GET /v1/approvals/:id | Your organization's approval requests and their status (pending, approved, denied, consumed or expired). After an approval_required answer, poll the one you were given, then repeat the identical request once it is approved. The decision link is never in an API response. | DELETE /v1/projects/:slug, POST …/undelete | Soft-delete a project (it stops serving; code, database and backups are kept) and bring it back. With an approval-mode token the delete waits for a human approval. | GET /v1/status, /v1/alerts, /v1/platform/overview | Platform admin only. Host-wide health, current alerts and the operator overview. | ## What this page is not The list of routes and scopes is also generated by the server itself at /v1/capabilities and /v1/openapi.json, with no token needed. This page adds the request bodies and responses, written by reading the route files, so fields not mentioned here may exist. Where a body shape is not given, the route takes no body. ## Early-access scope - Request and response shapes here are hand-written, so some optional fields may be undocumented. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/changelog/ Developers # Changelog This is what has actually shipped in Stackap, by date; planned work is not listed here, and the home page keeps the honest roadmap. ## October 3, 2026 - A home page and a site of reference, comparison and guide pages, with plain-text summaries for language models. - Replicas: run 1 to 8 copies of an app behind a load balancer, with failover. Measured 426 requests per second with one copy and 683 with three on one 4-CPU server. - Multi-tenant organizations, with a single wall module, a static audit and 43 cross-organization attack tests, all refused. - Dashboards for tenants and operators, a per-push build timeline, per-project load-time metrics and a table browser and editor. - The control plane's own database is backed up to the bucket daily and restore-verified weekly. Failed-backup errors no longer carry connection strings. - Framework recognition: Next.js, single-page apps (Vite, Create React App, Vue CLI, Parcel), static-output sites (Astro, Docusaurus, Gatsby, Eleventy, VitePress), plain HTML, and Node apps with a start script. Per-project port and health path. - Human approvals for risky actions, soft delete and undelete for projects, and scoped, expiring, rotatable tokens, with a public description of the API at /v1/capabilities and /v1/openapi.json. - Contact-form leads, with a Leads view for the operator and a Telegram notice for each new one. - Storage on the open-source Supabase storage service in front of a Cloudflare R2 bucket, verified with 93 of 93 objects checksummed. - Encrypted git-repository backups. - Docker log rotation, a daily clean-up of old build images and cache, and a swap file. ## October 2, 2026 - First deploy path: git push over SSH to a build, a container, automatic HTTPS, failed-build and unhealthy-container protection, and rollback. - Domains with a DNS check before a certificate, a cron scheduler that imports vercel.json, logs, monitoring with Telegram alerts, the command-line tool and the dashboard. - A private Postgres database per project, and encrypted snapshot-consistent backups with a verified restore. - A Supabase-compatible data API, run for a real site. The platform is days old, so the log is short. Planned work is on the roadmap. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/cli/ Developers # CLI reference The Stackap command-line tool is a single program with one-line commands for creating projects, deploying, reading logs, managing variables and domains, and rolling back. ## Commands Command | What it does | login --url --token-stdin | Save the server address and token. The token can come from standard input so it never appears in shell history. | projects [--json] | List your projects, optionally as JSON. | create [--name ] | Create a project. | deploy [--remote-url ] | Push HEAD to the project's git remote, which triggers a build. | deployments | List a project's deployments. | rollback | Re-activate the previous deployment after a health check. | logs [--source build|runtime] [--limit N] | Read build or runtime logs. | env ls|set|rm [KEY] | List, set (value from standard input with --stdin) or remove an environment variable. | domains ls|add|rm [host] | List, attach or detach a hostname. | cron ls and cron import | List scheduled jobs, or import them from a vercel.json. | status | Overall health and every monitor check. Platform operators only. Exits non-zero when the overall state is failing. | db | Not implemented yet. | ## Authentication The tool stores the server address and token in a file in your home configuration directory, created with owner-only permissions. Log in once with stackap login --url https://api. --token-stdin and pipe the token in. Without a saved login, every command stops with the exact login command to run, so an agent that is not logged in can fix it without asking. ## Secrets Environment variables are set with --stdin, so the value comes from a pipe or a prompt and never from an argument that a process listing could show. The same rule applies to the login token. ## Output and exit codes Commands that list things print tables, and projects can print JSON. status exits non-zero when the overall state is failing, so it can sit in a script or a check. Errors print a message that says what to do next where one is known. ## What is not there There are no commands yet for backups, restores, scaling, project settings or organizations. Those are HTTP calls; see the agent documentation for the route table. The db command exists as a placeholder and is not implemented. ## Early-access scope - No backup, restore, scale or settings commands in the tool. Last updated 2026-10-03. --- Source: https://www.stackap.com/developers/docs/ Developers # Documentation Stackap's documentation is a set of pages organized by task, with the CLI and the API reference as the exact sources for commands and routes. ## Start here - The CLI reference lists every command, how secrets are passed and how failure is signalled. - The API reference lists every route with its request body and what it returns. - The agent documentation explains the plain-text site files and the rules an agent should follow. - The changelog says what has shipped and when. ## By task **Ship an app**: Read deployments, then the guide for your type of app: Next.js, React, Vite, Astro or Node.js. **Understand what is recognized**: The frameworks section says what Stackap detects and builds, and is explicit about what has not been tested. **Operate it**: See logs, monitoring, backups and rollbacks. **Move an existing app**: See the migration guides. ## How to read these pages Every product page ends with the limits of that feature, stated as plainly as what it does. Framework pages separate what has been built and served from what has only been reasoned about from the code. Comparison pages carry the date their facts about other products were last checked. Nothing is listed as supported until a real project of that kind has been built. ## What does not exist yet There is no public status page, no SDK and no per-endpoint schema file. Request and response shapes are documented in prose in the API reference, which was written by reading the routes themselves. If something here disagrees with what the server does, the server is right and the page is a bug; tell us at hi@stackap.com. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/ Frameworks # Frameworks Stackap recognizes a project by its dependencies, generates a container for it, and tells you exactly which frameworks that covers. Stackap recognizes a project by its dependencies, generates a container for it, and tells you exactly which frameworks that covers. The pages below describe what is recognized and how, what has been tested with a real build, and what has not. A framework is listed only when the platform handles it, and untested support is labeled as untested. ## Pages in this section - Next.js: How Stackap detects a Next.js project, the container it generates, how public and secret variables are handled, and what has been measured. - React: How a React app is served on Stackap: static single-page builds with client-side routing work, server components and server rendering do not. - Vite and React single-page apps: How Stackap builds Vite, Create React App, Vue CLI and Parcel single-page apps and serves them from nginx with a fallback to index.html. - Astro: How Stackap builds a static Astro site and serves it from nginx with real 404 pages, and why Astro with a server adapter is not treated as static. - Remix: Stackap does not recognize Remix by name. What its detection does with a Remix project, when a start script lets it run as Node, and what is untested. - Nuxt: Stackap does not recognize Nuxt by name. Why a Nuxt project skips the static path, how a start script changes that, and the untested caveats. - SvelteKit: Stackap does not recognize SvelteKit by name. How its detection treats the dependency, using the Node adapter with a start script, and what is untested. - Gatsby: How Stackap builds a Gatsby site and serves its public folder from nginx with real 404s, what Gatsby features need a server, and what is untested. - Docusaurus: How Stackap builds a Docusaurus documentation site and serves the build folder with a real 404 page, and the baseUrl setting that most often breaks it. - Eleventy: How Stackap builds an Eleventy site and serves the _site folder, and why a project with no build script in package.json is not recognized. - VitePress: How Stackap builds a VitePress site from.vitepress/dist, and why the default docs:build script name means you must add a build script first. - Node.js: How Stackap runs a Node.js app that has a start script: the generated image, the PORT contract, health checks and what is not supported. - Plain static sites: How Stackap serves a repository that is already a finished site, with an index.html at the root and nothing to build, and what is stripped from the image. - Python: Stackap has no Python support of its own. A Python app can run only if you provide a Dockerfile that listens on PORT, which is untested. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/astro/ Frameworks # Astro on Stackap Stackap builds a static Astro site in a container and serves the output from nginx with genuine 404 responses; an Astro project that uses a server adapter is deliberately not treated as static. ## How Stackap recognizes Astro A project is treated as a static site when it has a build script, lists astro as a dependency, and does not list a server adapter. The adapters that disqualify it from the static path are @astrojs/node, @astrojs/vercel and @astrojs/netlify, because those produce server code, not files. The same static path serves Docusaurus, Gatsby, Eleventy and VitePress. ## What Stackap builds The image builds your site with the package manager the lockfile implies and copies the output into nginx. Unlike the single-page-app path, unknown URLs return a real 404 page, which is what a content site wants for search engines. Because nothing runs on the server, there is nothing to start, nothing to crash and almost no memory use. It is the cheapest kind of app to host on one box. ## What a Astro project needs - Astro configured for static output, which is its default. - A build script that writes the finished site. - No server adapter in the dependencies. If you have one only for local development, remove it for the production build. - A 404.html or 404 page if you want a custom not-found screen. ## Verification status The static-site path is covered by a real Docker build in the platform's test suite. This site, www.stackap.com, is itself a static site served by a similar nginx container, built from its own Dockerfile, though it is generated by a Python script and not by Astro. Still to verify: an Astro project built end to end by us. We have not shipped an Astro site on Stackap, so treat Astro-specific behavior, such as content collections or image optimization at build time, as unverified. An Astro project with a server adapter is either treated as a Node app, if it has a start script, or refused with an explanation. ## Early-access scope - No Astro site has been deployed on Stackap by its builders yet, so the support rests on the generic static-site path and its tests. - Server-side rendering and on-demand routes are not supported through the static path. - Image optimization that runs at request time on another platform has no equivalent here; build-time optimization works because it produces files. - No CDN, so the same latency caveat as every other Stackap site applies. ## Questions **Q: Can I use Astro with SSR?** Not through the static path. With a server adapter it would need to run as a Node app, which is untested for Astro, so we do not claim it works. **Q: Does it return real 404s?** Yes. Static-site frameworks are served with true 404 responses, unlike single-page apps. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/docusaurus/ Frameworks # Docusaurus on Stackap Stackap builds a Docusaurus documentation site and serves the build folder from nginx, using the 404 page Docusaurus generates. ## How Stackap recognizes Docusaurus A project counts as a Docusaurus site when it has a build script and lists @docusaurus/core as a dependency. It takes the static-site path, which returns real 404 responses. Docusaurus's default scripts include a build script, so no renaming is needed. ## What Stackap builds Docusaurus writes its finished site to build, which is on Stackap's list of output folders. The generated image runs the build, copies that folder into nginx, and serves it. Docusaurus also writes a 404.html, which Stackap's nginx configuration is set to use for missing pages, so your own not-found page appears with a real 404 status. The one setting that most often breaks a first deploy is baseUrl. It defaults to /, which is correct for a site on its own domain. Projects that were published under a sub-path, such as a repository name, often carry a different value that must be changed back. ## What a Docusaurus project needs - The default build script. - A baseUrl of / unless the site really lives under a sub-path. - A correct url in the config, so canonical links and the sitemap are right. - A lockfile. ## Verification status The shared static path has a real Docker build in the platform tests. Still to verify: a Docusaurus build by us, including versioned docs, the search plugin, or internationalization with several locales, which write extra folders. ## Early-access scope - No Docusaurus site has been shipped on Stackap yet. - Search that relies on an external service works only if that service is reachable from visitors' browsers; Stackap provides none. - Large documentation sites build slowly and use memory the live apps share. - The generated build image uses Node 24, so a project that needs an older Node should bring its own Dockerfile. - No CDN, so distant readers see more latency. ## Questions **Q: Why are my links broken after deploying?** Almost always baseUrl. Set it to / for a site on its own domain. **Q: Can I use versioned docs?** Versioned docs are folders in your repository that Docusaurus builds into the output, so there is nothing Stackap-specific. A long version history lengthens the build, and the build shares the machine with live apps. **Q: Does it handle several languages?** Docusaurus writes each locale to a subfolder, which the static server serves like any other path. We have not tested it end to end. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/eleventy/ Frameworks # Eleventy on Stackap Stackap builds an Eleventy site and serves its _site folder from nginx, but only when package.json has a build script, which Eleventy projects often lack. ## How Stackap recognizes Eleventy A project counts as an Eleventy site when it lists @11ty/eleventy as a dependency and has a script named build. Eleventy is commonly run directly from the command line, and many projects define only start or serve. Without a build script, detection never reaches the Eleventy case, and the project could instead be mistaken for a Node app if it has a start script that runs the development server. ## What Stackap builds The fix is one line: add "build": "eleventy" to the scripts. After that the generated image runs it and copies the _site folder, Eleventy's default output, into nginx. If you changed the output folder in your config, it must be one of the folders Stackap searches, or you can bring a Dockerfile. Eleventy produces plain HTML files, so the server returns real 404 responses and there is no application code to run. This is the lightest kind of site Stackap hosts. If your site uses a path prefix in its config, make sure it matches where the site is served, which for a domain of its own is the root. ## What a Eleventy project needs - A build script in package.json. - Output in _site, or in another folder from the searched list. - A lockfile. - No path prefix unless the site really lives under one. ## Verification status The static path has a real Docker build in the platform tests. A plain-HTML repository with no build at all has been served live on the server. Still to verify: an Eleventy build by us, or Eleventy plugins that fetch data over the network at build time. ## Early-access scope - No Eleventy site has been shipped on Stackap yet. - No build script means no recognition, and the failure message will not mention Eleventy. - Data fetched at build time is fetched during the Stackap build, so it needs the network and any secrets will be placeholders. - No CDN. ## Questions **Q: My site has only a plain index.html. Is that the same?** Almost. A repository with an index.html at the root and no start script is served as a plain static site with no build at all. See static sites. **Q: Why did my Eleventy site start a dev server?** It had a start script that runs one and no build script, so it was treated as a Node app. Add the build script. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/gatsby/ Frameworks # Gatsby on Stackap Stackap builds a Gatsby site with its build script, finds the finished pages in the public folder, and serves them from nginx with real 404 responses. ## How Stackap recognizes Gatsby A project is a Gatsby site when it has a build script, lists gatsby as a dependency, and has no server-rendering dependency from the excluded list. It then takes the static-site path, shared with Astro, Docusaurus, Eleventy and VitePress, which gives real 404s instead of the single-page-app fallback. ## What Stackap builds Gatsby writes its output to public. That folder is on the list Stackap searches, in an order that checks dist, build and out first, so a project that happens to have an index.html in one of those earlier folders would be served from there instead. A normal Gatsby project does not. The nginx stage caches scripts, styles, fonts and images for a day, and anything under /assets/ for a year, so a project that puts files under that path should give them hashed names. Image processing, which Gatsby does at build time, runs inside the build container. It is the heavy part of a large Gatsby build and uses memory the live apps also need. ## What a Gatsby project needs - A build script, normally gatsby build. - Static output only: no server-side rendering or deferred static generation that needs a server at request time. - A lockfile. - Enough build memory for your image count. ## Verification status The static-site path is covered by a real Docker build in the platform's own tests. Still to verify: a Gatsby project built by us. Gatsby-specific behavior, such as large image pipelines or plugins that call external services at build time, is unverified. ## Early-access scope - No Gatsby site has been shipped on Stackap yet. - Gatsby features that render on a server at request time are not served by this path. - Builds share the machine with live apps, so a very large site build can slow them for its duration. - No CDN in front of the files. ## Questions **Q: Does it need a plugin for Stackap?** No. Stackap only runs your build script and serves the result. **Q: Can I use Gatsby's image plugins?** Yes. They run at build time inside the build container and use the server's memory, so a large image set lengthens the build. **Q: Will cached builds speed up redeploys?** The generated image installs and builds from scratch each time. We have not added build caching, so do not expect the incremental speed Gatsby offers locally. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/nextjs/ Frameworks # Next.js on Stackap Stackap recognizes a Next.js project from its dependencies, generates a Dockerfile for it, builds it on the server, and runs it as a small non-root container behind automatic HTTPS. ## How Stackap recognizes Next.js A project is treated as Next.js when its package.json lists next as a dependency. That check runs first, before any other framework test, so a Next.js app is never mistaken for a plain Node app because it also has a start script. If your repository contains its own Dockerfile, Stackap uses that and skips detection. ## What Stackap builds The generated Dockerfile builds the app in one stage and runs the result in a slimmer one, as an unprivileged user. The image for one real site came out at 164 MB. Build-time variables follow a strict rule. Names beginning with NEXT_PUBLIC_ are passed in with their real values, because Next.js inlines them into the browser bundle and they are public by design. Every other variable is replaced by a placeholder during the build. That keeps secrets out of image layers, and it means code that reads a secret while the site is being statically generated sees the placeholder, so pages that need real data at build time have to fetch it when they are requested instead. At runtime the container receives the real values through a private file. The container runs with no new privileges and with CPU, memory and process limits. ## What a Next.js project needs - A build script and a start script, which Next.js projects have by default. - A lockfile. Stackap chooses npm, Yarn or pnpm from the lockfile it finds, and npm ci fails if the lockfile is stale. - Public variables named NEXT_PUBLIC_*, set before you push, because they are baked in at build time and changing one later needs a new build. - Image hosts declared in your Next.js config if you use remote images. ## Verification status Tested with real builds: a 31,592-page Next.js site builds on the server in about 96 seconds with a peak of roughly 2.8 GB of memory, serves the same pages as the live original (26 pages plus 64 sampled sitemap URLs compared), and passes a load test of about 410 requests per second with no errors on one copy, rising to roughly 700 with three copies on the 4-CPU box. Still to verify: the Next.js image cache across restarts, incremental static regeneration across several servers (the cache is per server today), and Next.js features that depend on a vendor's edge network, such as edge middleware running at a distant location. ## Early-access scope - Only the generated single-container setup is supported. Splitting one Next.js app across several services is not. - There is no edge network. Server-rendered pages come from one machine, which today is in Germany. - Incremental static regeneration caches live on the server that rendered them, so running several copies on one box works but multi-server setups are not built. - Variables that must be real at build time other than NEXT_PUBLIC_* are not supported by the placeholder rule. ## Questions **Q: Does Stackap need a vercel.json?** No. If you have one, Stackap can import its cron entries with stackap cron import, but it does not otherwise read it. **Q: Which Next.js versions work?** We have not tested a version range. The real site that was moved uses the version it ships with, and detection only looks for the next dependency. **Q: Can I run more than one copy?** Yes, up to eight per project on one server, set by the platform operator. They share a load balancer with failover. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/nodejs/ Frameworks # Node.js on Stackap Stackap runs any Node.js app that has a start script: it installs dependencies, runs your build if you have one, and starts the app as a non-root process that must listen on the port it is given. ## How Stackap recognizes Node.js Node is the last test, tried after Next.js, the static-output frameworks and a plain index.html. A project qualifies when package.json has a start script. A repository with an index.html and no start script is served as a plain static site instead. If none of these match and there is no Dockerfile, the build is refused with the reason. ## What Stackap builds The generated image installs dependencies with npm, Yarn or pnpm depending on the lockfile, runs the build script when one exists, and runs npm start as an unprivileged user. Your app must listen on the port passed in the PORT environment variable, not a number you hard-coded. Health is judged by an HTTP request. By default Stackap asks the app's port for a successful response on a default path. An API with no page at the root should be given its own port and health path in project settings, for example port 8080 and /healthz, which is the combination that was tested with a toy API. ## What a Node.js project needs - A start script that starts a server and does not exit. - The app reads PORT from the environment. - A health route that returns a success status when the app is ready. - Secrets only in environment variables set through Stackap, never in the repository. ## Verification status Tested with real Docker builds of the generated Node image and, live on the server, with a toy API-only app that was refused with default settings and served correctly once given a port and health path. Still to verify: long-running workers with no HTTP port, WebSocket-heavy apps, apps that need system packages beyond what the base image has, or any particular framework such as Express or Fastify (they should behave as Node apps, but we have not run each). ## Early-access scope - The app must serve HTTP. A background worker with no port cannot pass a health check today. - One container per copy and no sidecars. Anything that needs a second process alongside the first needs its own Dockerfile. - Server-rendering frameworks such as Remix, Nuxt and SvelteKit are not recognized by name. They might run as Node apps with a start script, but that is untested and we do not claim it. - There is no persistent disk for the container. Files written at runtime are lost on the next deploy, so use the database or object storage. ## Questions **Q: Does it support Python?** No. Python is not supported yet, and we will not list it as a supported framework until it is. **Q: Where do uploads go?** Not to the container's disk. Use the project's Postgres database or S3-compatible object storage. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/nuxt/ Frameworks # Nuxt on Stackap Stackap does not recognize Nuxt yet: a project that depends on nuxt skips the static path, and it needs a start script or a Dockerfile of its own to run. ## How Stackap recognizes Nuxt A dependency named nuxt keeps a project off the static-site path, because a Nuxt app is built to render on a server. After that, detection looks for an index.html at the repository root, finds none, and then looks for a start script. A fresh Nuxt project does not usually define one; its scripts are typically build, dev and preview. With none, the build is refused with a reason. ## What Stackap builds There are two honest routes. The first is to add a start script that runs the production server Nuxt produces, so that Stackap treats the project as a Node app. The second is to bring a Dockerfile that builds and starts the app, which Stackap uses as it is. Nuxt can also generate a fully static site. A static output step that writes an index.html into.output/public is not on the folder list Stackap searches, so a statically generated Nuxt site needs its output moved to a folder the list does contain, such as dist, and the project would still need to avoid the nuxt dependency check, which is not something we have worked out. In every case the app must listen on PORT and answer a health request. ## What a Nuxt project needs - Either a start script or your own Dockerfile. - The production server bound to PORT, not a fixed number. - A health route. - Public and secret values separated: only prefixed public values belong in client code. ## Verification status Verification pending. No Nuxt project has been built or served on Stackap, and the static-generation route above is unresolved, not merely untried. The generic Node path and the Dockerfile path are tested with other projects. ## Early-access scope - Nuxt is not a supported framework today. - A statically generated Nuxt site does not fit the static path as detection stands, because the nuxt dependency excludes it. - Nitro features aimed at edge or serverless runtimes have no equivalent. - Only HTTP servers are supported, with no persistent disk. ## Questions **Q: Why not just add Nuxt to the list?** Because adding it without building a real project would be a claim we cannot back. The list grows when a project of that kind has been served. **Q: What is the quickest way to try?** Write a small Dockerfile for your Nuxt app that listens on PORT, push it to a test project, and read the logs. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/python/ Frameworks # Python on Stackap Stackap has no Python support of its own: it generates images only for Node-based projects and static sites, so a Python app can run only from a Dockerfile you provide. ## How Stackap recognizes Python Detection reads package.json and the files at the root of the repository. There is no check for requirements.txt, pyproject.toml or any Python framework, so a Python project without a Dockerfile is refused with a stated reason, and whatever was live keeps serving. ## What Stackap builds If your repository contains a Dockerfile, Stackap builds and runs it instead of generating anything. A Python web app can therefore run, in principle, as long as the image starts a server that listens on the port in the PORT environment variable, runs as an unprivileged user, and answers a health request. Everything else on the platform is language-neutral: the database, the environment variables, the domains, the logs, the backups and the rollbacks do not depend on what the container runs. We have not built a Python app on Stackap, so this is a description of how the Dockerfile path works for any language, not a tested Python recipe. ## What a Python project needs - A Dockerfile at the root of the repository. - An image that listens on PORT, not a fixed number. - A route that answers a health check, with the port and path set in project settings if they differ from the defaults. - Database access through DATABASE_URL. ## Verification status Not tested with Python. The Dockerfile path itself is exercised: a repository that brings its own Dockerfile is built from it, and this very site is deployed that way. ## Early-access scope - Python is not a supported language today, and we will not list it as one until a real app has been served. - No generated image means no dependency caching and no help from detection when a build fails. - The container has no persistent disk and no second process alongside the first. - Workers with no HTTP port cannot pass a health check yet. ## Questions **Q: Will Stackap add Python?** It is on the list of things that people ask for. We have not set a date, and it will not be announced as supported before a real project has run. **Q: Can I run a Flask or FastAPI app?** With your own Dockerfile and a server such as one that listens on PORT, it should work, but it is untested. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/react/ Frameworks # React on Stackap A React app runs on Stackap as a static single-page app when it is built with Vite or Create React App, and as a server when it is built with Next.js; React itself is not what Stackap detects. ## How Stackap recognizes React Stackap never looks for react in your dependencies. It looks at the tool that builds the app. If that tool is Vite, Create React App (react-scripts), Vue CLI or Parcel, with a build script and no server-rendering framework, the app is served as static files. If the app depends on next, it is a Next.js app. Anything else with a start script runs as a plain Node app. ## What Stackap builds For a React single-page app the generated image runs your build, then copies the first of the usual output folders that contains an index.html. A Vite app writes to dist and a Create React App project writes to build; both are on the list. If none contains an index.html, the build stops with a message naming the folders it looked in. The web server in front of the files sends every path that is not a real file to index.html, so a client-side router such as React Router can handle a deep link like /account/settings opened directly or refreshed. Create React App is no longer recommended for new projects by the React team, and its build tooling is old, so a new app is better started on Vite. Existing Create React App projects build and are served the same way. ## What a React project needs - A build script that produces an index.html in one of the standard folders. - Public values prefixed the way your tool requires, VITE_ for Vite and REACT_APP_ for Create React App. They are compiled into the files, so none may hold a secret. - A router configured for the root of the domain, not a sub-path, unless you have set its base path to match. - A separate backend for anything that needs a secret or a database, since a single-page app has no server of its own. ## Verification status The single-page-app path has a real Docker build in the platform's test suite, including the index.html fallback. Still to verify: React Server Components, streaming server rendering, or any React framework with its own server runtime other than Next.js. Those need a server, and the static path will not run one. ## Early-access scope - Only the browser half of React is served. Server components and server rendering need Next.js or a Node server of your own. - Because unknown paths return the app shell, a mistyped URL is a 200 response with the app's own not-found screen, not an HTTP 404. That matters for search engines, so prefer a pre-rendering tool if you rely on crawling. - A React Native or Expo project is not a web app and is out of scope. - No content delivery network in front of the files. ## Questions **Q: Do I need Next.js to host React?** No. A plain React single-page app builds and runs as static files. Next.js adds a server, which Stackap also supports separately. **Q: Why is my environment variable undefined?** It lacked the public prefix, so the build tool did not include it. Add VITE_ or REACT_APP_, and remember it is then readable by every visitor. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/remix/ Frameworks # Remix on Stackap Stackap does not recognize Remix yet: a Remix project is kept off the static path on purpose, and it can run only as a generic Node app if it has a start script, which has not been tested. ## How Stackap recognizes Remix Any dependency that starts with @remix-run/ disqualifies a project from the static-site path, because a Remix app renders on a server and its build output is not a folder of finished pages. Detection then continues down its list: there is no index.html at the root, so the plain-static case does not apply, and the only remaining match is a start script, which would make it a Node app. ## What Stackap builds If your Remix project has a start script, Stackap would generate the Node image: install with the package manager the lockfile implies, run the build script if there is one, and run the start script as an unprivileged user. Remix's starter templates usually define such a script, which serves the compiled server bundle. The app would have to listen on the port Stackap passes in the PORT variable, and answer a health request on the default path or one you configure. If there is no start script and no Dockerfile, the build is refused with a stated reason and whatever was live keeps serving. You can always bring your own Dockerfile, which Stackap uses in place of detection. ## What a Remix project needs - A start script that launches the production server and does not exit. - The server reading PORT from the environment. - A route that answers a health check. - Secrets set through Stackap, not committed. ## Verification status Verification pending. No Remix app has been built on Stackap. The reasoning above comes from reading how detection works, not from running a Remix project. What is tested is the generic Node path, with a toy API, and the rule that a project with no usable start script is refused. ## Early-access scope - Remix is not a supported framework today. Treat this page as an explanation, not a promise. - Remix's server runs as a long-lived Node process, so the limits of the Node path apply: HTTP only, no persistent disk, one container per copy. - Platform features that a Remix adapter may rely on, such as edge runtimes, are not available. ## Questions **Q: Will it ever be supported?** We do not publish a date. A framework is added only when a real project of that kind has been built and served, and this one has not. **Q: Can I try it anyway?** Yes, if you are invited. Add a start script or a Dockerfile, deploy to a test project, and read the build and runtime logs. Tell us what you find at hi@stackap.com. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/static-sites/ Frameworks # Plain static sites on Stackap A repository with an index.html at its root and no start script is served as a finished static site with no build step at all. ## How Stackap recognizes a plain static site After the framework tests, Stackap checks for an index.html at the repository root when there is no start script in package.json, or no package.json at all. A match is treated as a site that is already built. This is the path a hand-written site, an export from a design tool or a folder of generated files takes. ## What Stackap builds The generated image copies the whole repository into the web server's folder and then deletes the files that should not be public: the Stackap nginx configuration, the Dockerfile and the.dockerignore. Everything else you committed is served, so do not leave private files in the repository. There is no build, so there is nothing to wait for and nothing that can fail on a missing dependency. This site is served by a similar nginx container, built from its own Dockerfile, with its pages generated by a script before they are committed. Pages return real 404 responses, using a 404.html if you provide one. ## What a a plain static site project needs - An index.html in the root of the repository. - No start script in package.json, or no package.json. - Nothing committed that you would not publish, because the whole repository is served. - Relative or root-absolute links, since there is no router. ## Verification status Tested with a real Docker build of the plain-static image in the platform's tests, and live on the server with a toy project. Still to verify: very large repositories, or sites with thousands of files. ## Early-access scope - The whole repository is public. A stray.env or a source file will be served if it is committed. - Nothing runs on the server, so forms need an external service or a separate Node project. - A package.json with a start script sends the project down the Node path instead, even if an index.html exists. - No CDN. ## Questions **Q: How do I add a custom 404?** Put a 404.html in the root. The server uses it for missing paths. **Q: Can I add a build step later?** Yes. Add a package.json with a build script and one of the supported tools, and detection will take the static-site path instead. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/sveltekit/ Frameworks # SvelteKit on Stackap Stackap does not recognize SvelteKit yet: the @sveltejs/kit dependency keeps a project off the static path, and it runs only if you give it a start script or a Dockerfile. ## How Stackap recognizes SvelteKit The dependency @sveltejs/kit excludes a project from the static-site path, since SvelteKit decides at build time whether it produces static pages or a server, through an adapter. Stackap does not read the adapter. With the static path ruled out, detection looks for a root index.html, finds none, and then for a start script. ## What Stackap builds The route that fits Stackap best is the Node adapter. It writes a self-contained server into a build folder, which you start with node build. Put that command in a start script, make sure the server reads PORT, and Stackap will build the project and run it as a Node app. A SvelteKit site built with the static adapter writes finished pages, often into a build folder with an index.html. Stackap would not take it down the static path because of the dependency check, but a Dockerfile of your own that copies those pages into a small web server works regardless. Either way the same health-check and port rules as every other Node app apply. ## What a SvelteKit project needs - The Node adapter and a start script, or a Dockerfile. - The server listening on PORT. - A route that answers a health check. - Public variables using SvelteKit's public prefix, never secrets. ## Verification status Verification pending. No SvelteKit project has been built on Stackap. The two routes above come from reading how detection and the adapters work. ## Early-access scope - SvelteKit is not a supported framework today. - The static adapter's output is not detected automatically, because the dependency check comes first. - The generated build image uses Node 24, so a project that needs an older Node should bring its own Dockerfile. - Adapters for edge and serverless platforms have no equivalent here. - No persistent disk, and no process other than the one server. ## Questions **Q: What about Svelte without SvelteKit?** A Svelte app built with Vite alone is a single-page app, and it takes the Vite path like any other. **Q: Which adapter should I use?** The Node adapter, with a start script, is the closest fit. It is the route most likely to work, but it is untested here. **Q: Does it work with the static adapter?** Only through your own Dockerfile today. Detection will not take it down the static path. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/vite/ Frameworks # Vite and single-page apps on Stackap Stackap builds a Vite, Create React App, Vue CLI or Parcel project in a container and serves the output from nginx, sending unknown paths to index.html so client-side routing works. ## How Stackap recognizes Vite A project counts as a single-page app when it has a build script and lists vite, react-scripts, @vue/cli-service or parcel as a dependency. Dependencies are checked before scripts on purpose: Vite and Create React App both define a start script that launches a development server, and treating them as Node apps would deploy a dev server to production. React apps are covered by this path whether they use Vite or Create React App. ## What Stackap builds The generated image has two stages. The first installs dependencies with the package manager the lockfile implies and runs your build script. The second is nginx, which serves the build output and falls back to index.html for any path that is not a file, so a route such as /settings opened directly does not return a 404. Because the result is static files, there is no server code to run, memory use is tiny, and a build-time variable is baked into the files. Anything prefixed the way your bundler requires for public values, for example VITE_ in Vite, is visible to every visitor and must never hold a secret. ## What a Vite project needs - A build script in package.json. - No server adapter. A Remix, Nuxt or SvelteKit project that renders on a server is a different case and is not served this way. - A lockfile, so the install is reproducible. - API calls to a separate backend, since a static app has no server of its own. Point it at a Stackap project that does. ## Verification status Tested with a real Docker build of the generated image for the single-page-app path, including the index.html fallback, as part of the platform's own test suite. Still to verify: a catalogue of individual Vite versions, plugins that write their output somewhere unusual, or monorepos where the app is not at the repository root. ## Early-access scope - Static output only. Anything that needs to run code on the server is out of scope for this path. - The fallback sends every unknown path to index.html, so a mistyped URL returns the app's shell with a 200 status instead of a true 404. Static-site generators on the next page behave differently and return real 404s. - There is no content delivery network in front of the files, so visitors far from the server see more latency. - Monorepo layouts are untested. ## Questions **Q: Does it work for React?** Yes, when the React app is built with Vite or Create React App. Next.js is handled separately because it has a server. **Q: Why is a missing page not a 404?** A single-page app handles its own routing in the browser, so the server returns the shell for unknown paths and lets the app decide. That is the standard trade-off for this kind of app. Last updated 2026-10-03. --- Source: https://www.stackap.com/frameworks/vitepress/ Frameworks # VitePress on Stackap Stackap builds a VitePress site and serves its.vitepress/dist folder, but VitePress's default script is named docs:build, so you need to add a script called build first. ## How Stackap recognizes VitePress A project counts as a VitePress site when it lists vitepress as a dependency and has a script named build. VitePress's documentation suggests docs:dev, docs:build and docs:preview. None of those is called build, so a project created from the guide is not recognized until you add an alias. ## What Stackap builds Add "build": "vitepress build docs", adjusting the folder to wherever your pages live. The generated image runs it, then looks for the output in.vitepress/dist or docs/.vitepress/dist, which are the two VitePress locations on Stackap's list. The result is plain HTML, served by nginx with real 404 responses. VitePress has a base option for sites published under a sub-path. On a domain of its own it should be /. ## What a VitePress project needs - A script named exactly build. - Output in one of the two.vitepress/dist locations. - A base of / for a site on its own domain. - A lockfile. ## Verification status The folder names are on the list the generated Dockerfile searches, and the shared static path has a real Docker build in the platform tests. Still to verify: a VitePress build by us. ## Early-access scope - No VitePress site has been shipped on Stackap yet. - The default script names are not recognized, so a project created straight from the documentation fails until you add a build script. - The failure in that case is "unrecognized project", which does not name VitePress. - The generated build image uses Node 24, so a project that needs an older Node should bring its own Dockerfile. - No CDN. ## Questions **Q: Is a sub-path deployment supported?** The server serves whatever your build produces from the root of the domain, so a site built with a sub-path base will have broken links on its own domain. Build it with base: "/". **Q: Does it get a custom 404 page?** VitePress writes a 404.html, which the web server uses for missing paths, so your not-found page is served with a real 404 status. **Q: What if my docs are in a subfolder?** Put that folder in the build script you add. Stackap searches both.vitepress/dist and docs/.vitepress/dist, so either layout works without further settings. **Q: Does search work?** VitePress's built-in local search is generated at build time into the output, so it works from the static files. We have not tested it ourselves. Last updated 2026-10-03. --- Source: https://www.stackap.com/get-started/ Start here # Get started You ask for an invitation, we create your organization, and your coding agent or your own terminal takes an app from a repository to a live address in a few commands. ## What you need - An application in a git repository. Next.js, a single-page app, a static site, or any Node app with a start script works, and so does anything with a Dockerfile. - A coding agent that can run shell commands, or a terminal you are comfortable in. - A domain name, if you want your own address. It is optional: every project gets an address of its own the moment it is created. ## How early access starts You begin as an organization on the Stackap server. That is a walled-off space with its own projects, its own access token, its own git key and its own dashboard sign-in, so nothing you do can be seen by anyone else on the server. If your team later needs a server dedicated to it, that is set up together with you during onboarding. Nobody in early access has to rent or configure a machine to get started. ## What a deploy looks like The timings below are from a real push of this very website to Stackap: 1.2 seconds queued, 1.4 seconds building, 0.3 seconds switching traffic, 2.9 seconds in total. Across the last nine pushes the average was 2.2 seconds. A site this size is the best case, and a large application takes as long as its build does: a 31,592-page Next.js site builds in about 96 seconds. $ stackap deploy my-app remote: stackap: build queued remote: building image........ ok remote: health check......... ok remote: routing swapped....... live previous version kept for rollback ## Hand this to your coding agent Paste the prompt below into Claude Code, Codex or any agent that can run commands. It tells the agent where to read, how to handle secrets, when to stop and ask you, and the exact steps. It uses only commands that exist today. You are going to deploy an application to Stackap, a platform you operate through its command-line tool and HTTP API. First read these, in order: 1. https://www.stackap.com/llms.txt 2. https://api.stackap.com/v1/capabilities (every route, scope and error code; no token needed) Rules: - Never put a secret on a command line. Pass secrets on standard input (--stdin). - If a deploy does not go live, read the build log and then the runtime log before changing any code. - Ask me before deleting anything and before pointing a production domain at the server. - If a call answers approval_required, tell me, wait for my decision, then repeat the identical request. Task: 1. Log in: stackap login --url https://api.stackap.com --token-stdin (I will give you the token.) 2. Create a project: stackap create my-app --name "My App" 3. Set each environment variable: stackap env set my-app KEY --stdin 4. Deploy: stackap deploy my-app 5. Read the result: stackap logs my-app --source build 6. Tell me the live address and what you checked. The agent will stop and ask you in three places, on purpose: before it deletes anything, before it points a production domain, and whenever the platform asks for a human approval. Everything else it can do on its own. ## If something goes wrong **The build fails**: The previous version keeps serving. Read the build log with stackap logs my-app --source build; it says what Stackap detected and why it stopped. **The build passes but the app does not go live**: The health check failed. Read the runtime log, and check that your app listens on the port in PORT and answers on its health path. **The new version is wrong**: stackap rollback my-app brings the previous one back after checking it is healthy. **The push is rejected**: Your SSH public key is not registered with your organization yet. We register it during onboarding, or an owner token can do it through the API. ## Steps - Ask for an invitation. Tell us what you run on the contact page. Early access is limited, and a person replies by email. - Receive your organization. You get an access token, shown once, a git key registration and a dashboard sign-in. The command-line tool is provided with your invitation. - Give your agent the prompt. Paste the prompt on this page into your coding agent, and hand it the token when it asks. - Watch the first deploy. The agent creates the project, sets variables, pushes, and reads the build log. A small site is live in seconds. - Add your domain. Attach your hostname and create the one DNS record Stackap shows you. HTTPS switches on by itself once DNS is correct. ## Questions **Q: Do I need my own server?** Not to start. Early access begins as an organization on the Stackap server, and a dedicated server is arranged with you when you need one. **Q: Do I need to know DevOps?** No. You need to be comfortable giving a coding agent a token and approving what it asks about. The DNS record for a custom domain is the one step you or the agent does at your domain provider. **Q: Can I try it without a repository?** Not yet. Stackap deploys from git, so the app needs to live in a repository first. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/ Migrate # Migrate Guides for moving an existing app onto Stackap, with an inventory first and the known gaps stated before the steps. Guides for moving an existing app onto Stackap, with an inventory first and the known gaps stated before the steps. Each guide is based on a move that was actually done, and says which steps have been checked and which are still a plan. A migration is worth doing when a hosting bill has grown and the app is conventional. It is not worth doing for an app that sits comfortably inside a free plan, or one that depends on features Stackap does not have. ## Pages in this section - Migrate from Vercel: Moving an app from Vercel to Stackap when the database stays put: variables, crons, domain and the Vercel-only settings that need recreating. - Migrate from Supabase: Moving a Supabase database and storage onto Stackap: the tables and rows that copy, the functions that do not, and sign-in that blocks the move. - Migrate from Vercel and Supabase: The steps, the inventory and the known gaps for moving an app from Vercel and Supabase onto Stackap, based on the first real move. - Migrate from Railway: How to move an app from Railway to Stackap: split a multi-service project, copy variables and the Postgres data, and handle private networking. - Migrate from Render: How to move web services and static sites from Render to Stackap: environment groups, the Postgres dump, cron jobs, and the persistent disk question. - Migrate from Heroku: How to move a Heroku app to Stackap: map the Procfile to a start script, config vars to environment variables, Heroku Postgres to a project database. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-heroku/ Migrate # Migrate from Heroku Moving a Heroku app to Stackap means turning the Procfile web process into a start script, copying config vars into environment variables, moving the Postgres data, and replacing each add-on. ## Who this is for No team has migrated from Heroku to Stackap yet. This guide maps concepts and lays out the steps, and it is not a record of a tested run. The easiest Heroku apps to move are a single web process and a Postgres database. The hardest lean on worker dynos, a release phase and many add-ons, because each of those needs its own replacement. ## Take inventory first - The Procfile, line by line: web maps across, while worker, release and clock lines need a decision. - Every config var, from heroku config for the app. - Every add-on, from heroku addons, with what each one does for the app. - The buildpack in use. Node and static apps are recognized, and anything else needs a Dockerfile. - Scheduler jobs, and how often each runs. ## What does not move automatically **Worker and release processes**: A worker with no web port cannot run. A release phase that runs database migrations becomes a script you run before deploying, or a step at the app's start that is safe to repeat. **Add-ons**: Each add-on is replaced one by one: Postgres by the project database, Scheduler by cron jobs, and logging, search, queues or email by a service you connect with its own variables. **Review apps and pipelines**: There are none. Use a second project as staging. **The database copy**: There is no self-serve database import yet. The operator loads your dump into the project's database with you, and the row counts are compared table by table afterwards. ## How to know it worked - Row counts match table by table. - Every page and API route you rely on answers the same as on Heroku. - Each scheduled job runs once. - Anything that sends email or takes payments does so from one place only. ## Going back Keep the Heroku app until Stackap has carried real traffic. Going back is changing one DNS record. ## Steps - Capture the data. Take a backup with heroku pg:backups:capture and download it with heroku pg:backups:download. - Create the project. Create a Stackap project and add its git remote. - Turn the Procfile into a start script. Put the web command in a start script in package.json, and make the app listen on PORT. - Set the environment. Set each config var with stackap env set. - Load the database. The operator restores the dump into the project database with you. - Deploy and compare. Push, read the build log, and compare pages with the live Heroku app. - Switch. Point your domain's DNS record at Stackap, then turn off Heroku's Scheduler jobs so none runs twice. ## Early-access scope - The database load is operator-assisted, not self-serve. - Workers, release phases, pipelines and review apps have no equivalent. - Non-Node apps need a Dockerfile, which is untested for most languages. - No migration from Heroku has been run yet. ## Questions **Q: Does Stackap read my Procfile?** No. A web process becomes a start script, or you bring a Dockerfile. **Q: Will my dyno count carry over?** Not directly. An operator can run one to eight copies of the web process on the server. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-railway/ Migrate # Migrate from Railway Moving from Railway to Stackap means splitting a multi-service project into one Stackap project per web app, and removing any dependence on private networking between services. ## Who this is for No team has migrated from Railway to Stackap yet. This guide maps concepts and lays out the steps, and it is not a record of a tested run. A Railway project can hold several services that reach each other privately. A Stackap project is one app with its own database, so the work is deciding which of your services are web apps, which are data, and which need rethinking. ## Take inventory first - Every service in the Railway project, and which of them speak HTTP. - The variables on each service, including those that reference another service. - Any volume attached to a service. - Databases other than Postgres, and who connects to them. - Cron schedules and what each one calls. ## What does not move automatically **Private networking**: Apps cannot reach each other over a private network. They talk over their public addresses, or you combine them into one app. **Databases other than Postgres**: Only Postgres is provided, so Redis or similar needs another home. **Volumes**: Containers have no persistent volume. Use the database or object storage. **The database copy**: There is no self-serve database import yet. The operator loads your dump into the project's database with you, and the row counts are compared table by table afterwards. ## How to know it worked - Row counts match table by table. - Services that called each other privately now reach each other over public addresses and still work. - Scheduled calls run once. - No data was left on a Railway volume. ## Going back Keep the Railway project until the move is proven. Going back is one DNS record. ## Steps - Dump Postgres. Use the database's connection string with pg_dump for a full dump. - Create a project per web app. Each Railway web service becomes a Stackap project, deployed from its repository. - Flatten the variables. Where one service's variable referenced another, write the real value or public address into stackap env set. - Replace what does not move. Find a home for non-Postgres data and volumes first. - Load the database. The operator restores the dump into the project database with you. - Deploy and compare. Push, read the build log, and compare pages with Railway. - Switch. Point your DNS record at Stackap and stop the Railway services. ## Early-access scope - The database load is operator-assisted. - No private networking, volumes or databases other than Postgres. - A multi-service system becomes several projects, with more public calls between them. - No migration from Railway has been run yet. ## Questions **Q: What about a service that does not speak HTTP?** A queue worker or similar has no place in a Stackap project today. Keep it where it runs, or reshape it as a small web app with a health route. **Q: Will latency change?** Stackap runs on a server in Germany today. If your Railway region was elsewhere, expect a different latency to your users and to any database you leave behind. **Q: Can I keep the database on Railway?** Yes. The app can connect to it across the internet, with added latency to every query. **Q: Do I need a Dockerfile?** Not for Next.js, static sites or Node apps with a start script. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-render/ Migrate # Migrate from Render Moving from Render to Stackap is straightforward for web services and static sites, and needs a plan for background workers, persistent disks and command-style cron jobs. ## Who this is for No team has migrated from Render to Stackap yet. This guide maps concepts and lays out the steps, and it is not a record of a tested run. Render describes an app as a set of services, so the first job is to list them and sort each into one of three piles: moves directly, moves with a change, and does not move. ## Take inventory first - Every service and its type: web service, static site, background worker, cron job or Postgres. - The environment variables on each service, and any shared environment group. - Any persistent disk, and what the app writes to it. - The render.yaml file if there is one, since it records the whole setup. - The commands each cron job runs. ## What does not move automatically **Background workers**: A worker with no HTTP port cannot pass the health check. It can become a small web app with a health route, or stay where it is. **Persistent disks**: App containers have no persistent disk. Move what the app writes to the project database or to object storage first. **Command-style cron jobs**: Stackap cron calls a path on your app. The job's work has to become an endpoint, protected by a secret. **The database copy**: There is no self-serve database import yet. The operator loads your dump into the project's database with you, and the row counts are compared table by table afterwards. ## How to know it worked - Row counts match table by table. - Static pages return real 404s where they did before. - Each converted cron endpoint runs once per schedule. - Nothing the app wrote to a disk is missing. ## Going back Leave the Render services running until Stackap has carried real traffic, then remove them. ## Steps - Dump the database. Use the database's external connection string with pg_dump to take a full dump. - Create one project per web service. Each Render web service or static site becomes a Stackap project. - Move the variables. Copy each variable, including the shared group, with stackap env set. - Replace disks and workers. Rework anything that depends on a disk or a worker before cutover. - Load the database. The operator restores the dump into the project database with you. - Convert cron jobs. Expose each job's work as an endpoint and schedule a call to it, in UTC. - Deploy, compare and switch. Deploy, compare with the live service, then move the DNS record and disable Render's jobs. ## Early-access scope - The database load is operator-assisted. - No persistent disks, background workers or command-style cron jobs. - There is no render.yaml equivalent; projects are created by command or API. - No migration from Render has been run yet. ## Questions **Q: What happens to my Render database backups?** Download a full dump before you start and keep the Render database running until the move is verified. On Stackap, backups are daily and restore-verified weekly, so take a first one right after the data loads. **Q: Does a Render static site move easily?** Yes. It builds and serves from nginx with real 404s. See static sites. **Q: Can I move one service at a time?** Yes. Each service and its data can move on its own. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-supabase/ Migrate # Migrate from Supabase Moving from Supabase to Stackap means copying your tables and rows, carrying database functions over by hand, moving stored files and rewriting their URLs, and checking that the app does not depend on Supabase sign-in. ## Who this is for This is the data-side move: the app may stay where it is, or move later. The first thing to settle is sign-in. Stackap has no sign-in service, so an app that uses Supabase's cannot complete this move until it brings its own. If it does not, read on. The steps below come from the first real copy, a 43-table database of about 25,000 rows and 93 stored files, which now runs on Stackap. ## Take inventory first - Every table, with its row count, which becomes the check after the copy. - Every function, trigger, view, enum and extension. These are not copied with the rows. - Every storage bucket, whether it is public or private, and how many objects it holds. - Every database column that stores a URL to a file. - Whether any code calls Supabase sign-in, realtime or edge functions. ## What does not move automatically **Sign-in**: Not provided. Stop here if the app depends on it. **Functions, triggers and views**: In the inventory of one large product, 82 of 96 functions existed only in the live database. Extract each and apply it to the new database after the data. **Realtime and edge functions**: Not provided. **Policies that read the signed-in user**: They stay as Postgres, but nothing sets the user they read; rewrite them. **Storage URLs**: Rows that point at files need the new storage host written into them. ## How to know it worked - Every table's row count matches after the final copy. - Every stored file loads from its new URL, with a sample compared byte for byte. - Every function the app calls exists in the new database. - A real request exercises each feature that reads or writes data. ## Going back Keep the Supabase project until you are sure. Pointing the app back is changing its variables and redeploying. Do not let both databases accept writes at once. Choose a moment, make the final copy, and switch. ## Steps - Create the project and its database. Create a project and provision its database on Stackap. - Copy tables and rows. Run the copy tool. It can be run again and truncates and reloads the tables, so a final copy at cutover is cheap. - Apply functions, triggers and views. Create each by hand from the inventory, then run the app's own queries against it. - Move the files. Download every object, upload it to the new storage, compare checksums, and rewrite the stored URLs. - Point the app at the new data API. Change the data API address and keys in the app's variables, and deploy. - Compare. Check row counts table by table, then compare real pages built from the data. ## Early-access scope - Sign-in, realtime and edge functions have no equivalent. - The copy covers tables and rows only, and functions need the most care. - The only real move so far is the founder's own site. - Backups afterwards are daily with no point-in-time recovery, which is a step down from a hosted database. ## Questions **Q: Can I move just the database and keep my app on Vercel?** Yes. The app then talks to a database in Germany, so expect added latency. **Q: Does the app code have to change?** For data and storage calls, not in the one app tested. The addresses and keys change. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-vercel-and-supabase/ Migrate # Migrate from Vercel and Supabase Moving from Vercel and Supabase to Stackap means copying the database and files, recreating the environment variables, deploying the code, importing the cron jobs, and then changing one DNS record. ## Who this is for This is written from the first real move: a Next.js site with a 43-table Postgres database of about 25,000 rows and 93 stored files was copied to a staging project on Stackap and compared page by page with the live original. Its domain now points at the Stackap server. It is an operator-assisted process today, not a self-serve button. The copy tooling exists and is run for you, and the steps below are what is done and checked. If you are not already running an app that fits, read the gaps first. ## Take inventory first - Every environment variable the live app uses. Pull the production values, and note which are public (NEXT_PUBLIC_*) and which are secret. - Every table, and every database function, trigger, view and enum. Tables and rows are copied for you. The rest are not. - Every stored file, and every database column that holds a URL to one. - Every scheduled job. A vercel.json with cron entries can be imported directly. - Whether the app uses the hosted sign-in service. If it does, stop here. - The domain, who controls its DNS, and the record that currently points at the old host. ## What does not move automatically **Sign-in**: Stackap has no sign-in service. An app that depends on one cannot move until it brings its own. **Database functions, triggers and views**: The migrator copies tables and rows only. In the inventory of the founder's larger CRM, 82 of 96 database functions existed only in the live database and in no file in the repository, so extract and apply them yourself before cutover. **Storage URLs**: Rows that point at files must be rewritten to the new storage host. This was done with a script for 60 URLs in the first move. **Vercel-only settings**: Anything set only in Vercel, such as certain environment variables, headers, or redirects defined outside the repository, must be recreated by hand. **Preview deployments and edge features**: There is no equivalent. ## How to know it worked - Row counts match table by table after the final copy. - Every stored file loads from its new URL. - A sample of real pages is identical to the old site. - A real request exercises each integration the app uses, such as email or payments, in a safe mode. - Cron jobs fire once, not twice, on the first scheduled day. ## Going back Do not delete anything from the old host until the new one has served real traffic for a while. Going back is a DNS edit pointing the record at the old address, so keep the old project running until you are sure. Run the old and new sites with their schedules and any outbound messaging switched so that only one is live. Two copies of an app that both send email will send it twice. ## Steps - Create the project. Create a project on Stackap and give it its own database. - Copy the data. Run the migrator to copy tables and rows from the old database into the new one. It can be run again, so a final copy at cutover is cheap. Then apply the functions, triggers and views. - Copy the files. Download every stored object, upload it to the new storage, verify checksums, and rewrite the URLs in the database. - Recreate the environment. Set each variable with stackap env set. Public values are baked into the build, so set them before deploying. - Deploy and compare. Deploy to a staging hostname and compare it with the live site page by page. In the first move, 26 pages and 64 sampled sitemap URLs were identical. - Import cron jobs. Run stackap cron import with your vercel.json. - Cut over. Do a final data copy, attach the real hostname, and edit the single DNS record at your DNS provider so it points at the Stackap server. - Stop the old schedules. Disable the cron jobs on the old host, or they will run twice. ## Early-access scope - The process is operator-assisted. No customer has used it, and the one real move so far is the founder's own site. - Anything that depends on sign-in, realtime or serverless functions cannot move. - A DNS edit is a manual step, and Stackap will not change DNS for you. - Database functions and triggers need separate handling, and an app that relies heavily on them needs the most care. ## Questions **Q: How long does a move take?** We have no timing to publish. The one real move was done across several working sessions, and most of the effort went into inventory and checking. Expect it to scale with the number of database functions, files and integrations rather than with the number of pages. **Q: Will my site go down?** It should not need to. You run both side by side, compare them, and then change one DNS record, which propagates over minutes to hours. Lowering the record's cache lifetime a day beforehand makes the change land faster. Last updated 2026-10-03. --- Source: https://www.stackap.com/migrate/from-vercel/ Migrate # Migrate from Vercel Moving an app from Vercel to Stackap, with the database staying where it is, means deploying the code to a new project, recreating its variables and crons, and then changing one DNS record. ## Who this is for This is the shorter move: the app changes host and nothing else does. The database, if there is one, stays with its current provider and the app keeps connecting to it. If your database is on Supabase and you want it to move too, read the combined guide instead. The deploy half of this was exercised on a copy of a real Next.js site, whose domain now points at Stackap. ## Take inventory first - Every environment variable, pulled from the production environment, with public ones (NEXT_PUBLIC_*) noted separately. - Every cron entry in vercel.json. - Every domain and its DNS provider. - Anything configured only in the Vercel dashboard: headers, redirects, rewrites, regional settings, firewall rules and analytics. - Whether the app uses Vercel-specific packages for storage, key-value or edge functions. ## What does not move automatically **Preview deployments**: There are none. Use a second project as staging. **Edge and serverless functions**: Routes that run at the edge or as separate functions have to run inside the app on a container. **Vercel-only storage products**: Anything stored in a Vercel product must be moved to the project's own database or storage first. **Dashboard-only rules**: Headers, redirects and rewrites defined outside the repository must be recreated in the app's own configuration. **Analytics**: Stackap shows server-side load time, not browser analytics. ## How to know it worked - The new site matches the old on a sample of real pages. - The app can reach its database and its third-party services from the new server's address, since IP allow-lists may need updating. - Each cron job fires once per schedule after the switch. - Email and webhooks still arrive, since callback URLs may have been tied to the old host. ## Going back Keep the Vercel project until Stackap has carried real traffic for a while. Going back is pointing the DNS record at the old address. Run only one copy of anything that sends messages or charges money. Two live copies would do it twice. ## Steps - Create the project. Create a project on Stackap and add its git remote to your repository. - Set the variables. Set public values first, because they are baked into the build, then secrets, each with stackap env set from standard input. - Deploy to the automatic address. Run stackap deploy and read the build log. Visit .stackap.com. - Compare. Open the old and new sites side by side and compare pages, including ones that read from the database. - Import crons. Run stackap cron import with your vercel.json. Do not stop the old ones yet. - Attach the domain. Run stackap domains add and create the A record it shows, after lowering the record's cache lifetime a day earlier. - Switch and stop the old schedules. Once traffic is on Stackap, disable the cron jobs on Vercel so jobs run once. ## Early-access scope - The domain switch is a DNS edit that you make by hand at your DNS provider. - No preview deployments, edge functions or browser analytics to move to. - The process is operator-assisted, since Stackap is invite-only. - A database that stays elsewhere may add latency, because the app now runs in Germany. ## Questions **Q: Does the database need to move too?** No. The app can keep using its current database, though distance to it affects speed. **Q: Will Vercel crons still run after I switch?** Yes, until you disable them. Do that deliberately, or every job runs twice. Last updated 2026-10-03. --- Source: https://www.stackap.com/pricing/ Pricing # Pricing Stackap is in invite-only early access, and pricing is arranged with each team as it joins. ## How it works today There is no public price list while Stackap is in early access. Each invited team agrees its terms directly, so they fit how the platform will actually be used. Teams who join early help shape the product, and the terms reflect that. ## What early access includes - Git deploys, HTTPS, per-project Postgres, file storage, scheduled jobs, logs, monitoring and encrypted backups. - Hands-on onboarding, including a first migration done together. - A direct line to the person building it. ## What to expect The first conversation is about fit: what you run, where it runs now and what you would like to be different. If Stackap suits you, we agree the terms and the first migration together. There is no automated sign-up, no card form and no sales sequence. Teams that join early also help decide what gets built next. ## How to start Tell us what you run on the contact page. We reply by email with a straight answer about whether Stackap fits, and what the next step is. ## Questions **Q: Is there a free tier?** No. Early access is arranged team by team, and there are no tiers yet. **Q: Do I need a card or a sign-up to ask?** No. The contact form asks for a name, an email address and a message. Nothing else is required, and nothing is charged. **Q: Will you publish prices?** We expect to when Stackap opens beyond early access. Teams in early access hear their terms directly first, so nobody learns their terms from a web page. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/ Product # Product Stackap is one server that does the work of several subscriptions: deploys, HTTPS, databases, storage, domains, scheduled jobs, backups and monitoring. Stackap is one server that does the work of several subscriptions: deploys, HTTPS, databases, storage, domains, scheduled jobs, backups and monitoring. Each page below describes one part of the product: what it does, how it works, and what it does not do yet. Pages for the rest of the platform are added as they are written, and nothing is listed here until it is true. ## Pages in this section - Deployments: How Stackap deployments work: a git push is built into a Docker image, health-checked beside the old version, and only then switched live. - Databases: How Stackap gives each project its own Postgres database and role, a Supabase-compatible data API, a table browser, and what it does not yet offer. - Storage: How Stackap stores uploaded files in a Cloudflare R2 bucket you own, served by the open-source Supabase storage service, and what is verified so far. - Domains: How Stackap attaches custom domains: one DNS record you create, a DNS check before issuing a certificate, automatic HTTPS, and expiry monitoring. - Cron jobs: How Stackap runs scheduled jobs by calling a path on your app, imports vercel.json crons, records every run, and what the schedule semantics are. - Environment variables: How Stackap stores secrets: AES-256-GCM encryption bound to project and name, values masked when listed, stdin-only input, and how build-time values work. - Logs: How to read Stackap build logs and live runtime logs from the CLI or API, the size limits and rotation, and what is not collected. - Monitoring: The checks Stackap runs on itself, how alerts reach Telegram, the per-project load-time metrics, and the blind spot of a monitor on the same machine. - Backups: How Stackap backs up databases and repositories to a bucket you own, encrypts them, and proves they restore, plus the gaps that remain. - Rollbacks: A Stackap rollback re-activates the previous deployment with one command, health-checking it first. What it restores, and what it cannot. - Scaling: How Stackap scales an app by running 1 to 8 copies behind a load balancer on one server, the measured throughput, and what multi-server scaling still lacks. - Agent-first infrastructure: What agent-operable infrastructure means in practice at Stackap: commands, an HTTP API and plain-text docs an agent can use without a human in the loop. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/agent-first-infrastructure/ Product # Agent-first infrastructure Stackap is an application platform that provides deployment, runtime, PostgreSQL, storage, domains, HTTPS, cron jobs, secrets, logs, metrics, monitoring, backups and rollback through an agent-operable control plane. ## What it does Most hosting products were designed for a person who clicks through a dashboard. The steps that cannot be done by a command, such as creating an account, finding a setting, copying a key from one screen to another, or reading a graph to decide what broke, are exactly the steps that stall a coding agent and send the work back to a human. Agent-first means designing the other way round. Every operation exists as a command and as an HTTP call. Commands that list things can print JSON (projects --json today). Errors are written to say what to do next: a CLI that is not logged in prints the exact login command. The documentation is plain text an agent can read in one request. A person still decides what to build and approves what matters, but the repetitive operating work has a path that does not need them. Four principles are used when deciding what to build. Do not send the human to a setting. Do not use the human as a courier between machines. Do not make the human diagnose something the agent can inspect. If the agent has to guess, the documentation has a bug. ## How it works Today the agent-facing surface is concrete and small: - A command-line tool whose commands are one line each and take secrets from standard input, so a token or a variable never appears in a process listing. The CLI reference lists every command. - An HTTP API with the same operations, authenticated by a token that belongs to exactly one organization. Scaling, settings and organization management are API calls. - Logs, deployments and health are readable from the same tools, so an agent can inspect a failure instead of asking a person to describe it. - Human approval for risky actions. With an approval-mode token, an action such as deleting a project returns approval_required; the account owner gets a decision link by a separate channel, approves or denies that exact request, and the agent then repeats it. Each approval is single-use and expires after an hour. - A public description of the API at /v1/capabilities and /v1/openapi.json, with scopes and error codes, so an agent can learn the surface without a token. - Plain-text descriptions of the site at /llms.txt and /llms-full.txt, generated from the same pages people read, so the two cannot disagree. See the agent documentation page. An agent's whole path to production is a handful of commands, listed under AI app deployment. ## In practice $ stackap projects --json $ stackap deploy my-app $ stackap logs my-app --source build $ stackap rollback my-app ## Early-access scope - There is no dedicated tool-protocol server for agents yet. An agent uses the command-line tool or the HTTP API. - Some steps still need a person, by design or for now. Risky actions wait for an approval, creating an organization is an operator action, and pointing a domain at the server is a DNS edit made at the DNS provider. - Documentation for agents is a single site summary and the CLI reference. A full, per-endpoint API reference has not been written. - "Agent-operable" describes the design goal and the current commands. It is not a claim that any particular agent will operate it without mistakes, and every destructive step still deserves a human's approval. ## Questions **Q: Does Stackap only work with AI agents?** No. Everything is also a normal command and a normal API, so a person can use it exactly as an agent does. **Q: Which agents does it work with?** We have not tested a list of products. Anything that can run a shell command or make an HTTP request can use it. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/backups/ Product # Backups Stackap backs up every project database to a bucket you own, encrypts the backup before it leaves the server, and restores it into a new database to prove it works. ## What it does Each project's Postgres database is dumped from a single consistent snapshot, so the data and the row counts recorded alongside it describe the same instant. The dump is encrypted with AES-256-GCM using a key derived from the master key, and the object's own name is bound into the encryption so a backup cannot be swapped for another and still verify. It is then uploaded to a Cloudflare R2 bucket in your account. A backup that has never been restored is a hope, not a backup. So once a week Stackap restores each backup into a fresh database and compares the table row counts with the manifest taken at dump time. A passing comparison sets a "restore verified" timestamp you can see. A failing one raises an alert. Restores only ever go into new databases. There is deliberately no button that overwrites a live database with a backup, because the most dangerous moment in recovery is the one where the fix destroys what survived. ## How it works A background loop checks hourly and does the work that is due: a backup per database each day, a verification each week, and pruning of old backups under a retention rule. Three things are backed up beyond the application databases: - The control plane's own database, which holds every project's configuration, encrypted environment variables and token hashes. It is backed up daily and restore-verified weekly. - Git repositories, as encrypted git bundles, so the source of an app does not live only on the server. - Object storage for projects that use it lives in R2 itself, and the storage schema in the database is included in the database backup. If a backup fails or goes stale, the monitor reports it, and a Telegram alert repeats every six hours until it is resolved. Errors from a failed backup are redacted so a database password cannot leak into a log or an API response. The one key that matters Backups and encrypted environment variables are unreadable without the master key. If it is lost, they are unrecoverable. Keep a copy somewhere other than the server, such as a password manager. ## In practice $ stackap status # overall health plus each monitor check, including backups ## Early-access scope - Backups are daily, so a disaster can cost up to a day of data. There is no point-in-time recovery yet; it is on the roadmap. - Restoring an off-box backup using only the bucket and the master key has been proven with a script on a separate machine, and rebuilding an entire fresh server from nothing is the next drill on the roadmap. - Restore verification compares table row counts. It proves the data came back at the right size, not that every value is correct. - Backups are only as independent as your bucket. They live in an R2 bucket in the same account the platform uses, so a lost Cloudflare account would lose them along with everything else you keep there. - The command-line tool has no backup or restore commands yet. Listing backups and restoring one into a new database are HTTP API calls (POST /v1/projects/:slug/restore). ## Questions **Q: Where do the backups live?** In a Cloudflare R2 bucket in your own account, encrypted before upload. Stackap runs on your server and your bucket, so there is no Stackap-operated storage anywhere in the path. **Q: Can I restore over the live database?** No, by design. Restores go into a new database, and you then point the app at it or copy what you need. **Q: How do I know a backup is good?** The weekly verification restores it into a scratch database and compares row counts with the manifest. The result is stored and shown, and a failure raises an alert. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/cron-jobs/ Product # Cron jobs A Stackap cron job is a schedule and a path: at each scheduled time Stackap calls that path on your app and records whether the call succeeded. ## What it does You define a job with a name, a standard five-field cron schedule and a path that starts with a slash. The scheduler is built into the platform, so there is no separate worker to run or pay for. When a job comes due, Stackap makes the request to your running app and stores the result. If your project already has cron entries in a vercel.json file, you can import them in one step with stackap cron import vercel.json. The job name is derived from the path. A set of 73 scheduled jobs from a real multi-tenant product passes the importer's validation. Every run is recorded with its status and any error, and the list of jobs shows the status and time of the last run, so an agent or a person can see which job is failing without reading logs. ## How it works Schedules are evaluated in UTC, always. A schedule written for another time zone has to be converted by hand, and daylight saving changes will shift the local hour. This matches how the hosted cron it imports from behaves. On each tick the scheduler looks for jobs whose most recent scheduled time has no run recorded yet and starts one, so a job is not skipped if a tick is late. A monitor check summarizes the cron system as healthy, warning when some jobs are flaky, and failing when some are down. - List jobs and their last result: stackap cron ls . - Create or change a job through the API: PUT /v1/projects/:slug/cron/:name with a schedule, a path and an enabled flag. - Read a job's run history: GET /v1/projects/:slug/cron/:name/runs. ## In practice $ stackap cron import my-app vercel.json $ stackap cron ls my-app ## Early-access scope - A job can only call a path on your own app. It cannot run a shell command or a script. - Schedules are UTC only. There is no time-zone setting. - If you move from another host, stop its cron jobs the moment the new ones are live, or every job will run twice. - Whether a job is retried after a failure is not a feature to rely on. Design endpoints to be safe to call again. - One server runs the scheduler, so a server outage pauses every job. ## Questions **Q: Does it support seconds or every-minute jobs?** Schedules use the five standard fields, so the finest grain is one minute. We have not tested very frequent schedules under load. **Q: How does the job authenticate to my app?** It makes an ordinary request to a path. If the path must not be public, protect it the way you would any endpoint, for example with a shared secret that you check yourself. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/databases/ Product # Databases Every Stackap project can have its own private Postgres database and its own database role, which can reach that database and nothing else. ## What it does Provisioning a database is one API call on a project. It creates a database and a login role for that project alone. The role has no superuser rights, cannot create roles or databases, and can connect only to its own database, which was checked with a cross-database test matrix that tried every project's role against every other project's database. The connection string is never returned by the API and never shown in the dashboard. It is injected into the app's container as DATABASE_URL when the container starts, and it is stored encrypted like any other secret. Two things sit on top of the database. A Supabase-compatible data API, served by PostgREST, lets code written against the standard JavaScript client read and write the same tables over HTTP. A table browser in the dashboard lets the project's owner look at tables, page through rows, sort and search, and insert or delete rows. ## How it works The table browser connects as the project's own role, not as an administrator, so it can only see what the app itself could see. Only the owner can write. Every browser write is recorded in the audit log with the column names that changed and never the values. The data API has been set up and exercised for one project, a real Next.js site, against the kinds of queries a large production codebase makes. Its data was copied across from a Supabase database, 43 tables and about 25,000 rows, with the row counts compared table by table. - Backups are taken from a single consistent snapshot, encrypted, and restore-verified. See backups. - Restores go into a new database, never over the live one. - Each project's database lives in the same Postgres server on the same machine as the apps. ## In practice POST /v1/projects/my-app/database # provision (once) GET /v1/projects/my-app/database # name and status, never credentials ## Early-access scope - The CLI has no database commands yet. The db command is a placeholder, and provisioning is an HTTP call. - All databases share one Postgres server and the machine's memory with every app on it. There is no read replica and no separate database server yet. - No point-in-time recovery. Backups are daily, so a disaster can cost up to a day of data. - The Supabase-compatible data API is set up by the operator and has been run for one project. It does not include sign-in, realtime or serverless functions. - Which Postgres extensions are available has not been documented or tested, so do not assume the ones a hosted product offers. - Moving a database in copies tables and rows only. Functions, triggers and views have to be carried over separately. ## Questions **Q: Can I connect with psql?** The database listens on the machine's local and internal networks only; its port is closed to the internet. Reaching it from outside means going through the dashboard's table browser or the data API, or through an SSH tunnel arranged by the operator. **Q: Is it the same as Supabase?** It is the same Postgres and the same data-API engine for the parts it covers. See Supabase vs Stackap for what is missing. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/deployments/ Product # Deployments A Stackap deployment turns a git push into a running, HTTPS-served app: the server builds an image, starts it beside the old version, checks that it is healthy, and only then switches traffic. ## What it does You push your code to your project's git remote on the Stackap server over SSH, or run stackap deploy , which pushes your current HEAD for you. Only pushes to the project's production branch start a build. Pushes to other branches are stored and ignored. If the repository has a Dockerfile, Stackap builds it. If it has none, Stackap generates one for the project types it recognizes: Next.js, single-page apps built with Vite, Create React App, Vue CLI or Parcel, static-output sites (Astro, Docusaurus, Gatsby, Eleventy, VitePress), a plain index.html, and Node apps with a start script. The frameworks section lists exactly what is recognized. A project Stackap cannot classify fails with a stated reason, and whatever was live keeps serving. Build-time secrets are handled deliberately. Variables beginning with NEXT_PUBLIC_ are passed through, because they are public by design. Every other variable is replaced with a placeholder while the image builds, so a secret is never baked into an image layer. Real values reach the container only when it runs, through a private file and not on a command line. ## How it works - Push. The push arrives at a restricted SSH user that can only send and receive git repositories. - Queue. A hook tells the control plane over a localhost-only, secret-protected endpoint. The push is recorded and a build is queued. - Build. Docker builds the image on the same machine. A 31,592-page Next.js site builds there in about 96 seconds, peaking near 2.8 GB of the server's 7.75 GB of memory. - Health check. The new container starts next to the old one and is polled until it answers successfully or a timeout expires. A container that crashes, hangs or errors is discarded, and no visitor was ever sent to it. - Swap. Only after the check passes does Stackap change the routing table, inside a database transaction, so the change happens completely or not at all. Caddy then sends traffic to the new container. Each project also has a port and a health-check path. They default sensibly and can be set per project by the owner (PUT /v1/projects/:slug/settings). An API-only app that does not answer on the default path needs its own; that case has been tested with a toy app on port 8080 and /healthz. ## In practice $ stackap deploy my-app $ stackap deployments my-app $ stackap logs my-app --source build $ stackap logs my-app --source runtime --limit 100 ## Early-access scope - No preview deployments. A branch other than production is stored but never built, so there is no per-branch preview URL. - No built-in test gate. Whatever builds and passes the health check on the production branch goes live, so run your tests before you push. - Builds run on the same machine as your live apps. A heavy build competes with them for memory and CPU. The 96-second build above did not disturb the other sites, but it is one measurement, not a guarantee. - Stackap does not watch GitHub or any other host. You add the project's Stackap git remote next to your existing one and push to it. - A repository with no Dockerfile that is not one of the recognized types is refused rather than guessed at. ## Questions **Q: Does a failed build take my site down?** No. A failed build or an unhealthy container never receives traffic. The previous version keeps serving, and the failure is recorded where stackap logs and the dashboard can show it. This was tested with a deliberately broken release. **Q: How long does a deploy take?** It depends on the build. The one large build measured, a 31,592-page Next.js site, took about 96 seconds. Other project sizes have not been benchmarked, so treat that as one data point. **Q: Do I need a Dockerfile?** Not for the recognized project types. If you have one, Stackap uses it instead of generating its own. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/domains/ Product # Domains To use your own domain on Stackap you attach the hostname to a project, create the one DNS record Stackap shows you, and the HTTPS certificate switches on by itself once DNS is correct. ## What it does Every project gets an automatic address under the platform's own domain, such as my-app.stackap.com, as soon as it is created. That is the address to use for testing and for a staging copy. For a real domain, you add the hostname with stackap domains add . The reply includes an instruction in the form of an A record: the name to create and the server's IP address to point it at. Stackap does not edit your DNS, because it is hosted with a different company, and it does not need to. Stackap checks that the name really resolves to the server before it asks for a certificate, and it reports two separate states for each hostname: the DNS status and the certificate status. Certificates are issued and renewed automatically by the web server in front of the apps. ## How it works - Attach the hostname to the project. The API returns the record to create. - Create the A record at your DNS provider. Lower its cache lifetime a day before any production switch so a change takes effect quickly. - Listing domains refreshes the status. When DNS resolves, the certificate is issued and traffic is routed to the project. - A monitor check reads the certificates actually being served and warns as they approach expiry. A hostname can only be attached to one project, and a request to attach one that is taken, or that would shadow another project's automatic address, is refused with the same response either way. The platform operator can additionally attach names under the platform's own base domain. ## In practice $ stackap domains add my-app www.example.com $ stackap domains ls my-app $ stackap domains rm my-app www.example.com ## Early-access scope - The DNS record is yours to create, by hand, at your DNS provider. Stackap never changes DNS and says so. - The instruction is a single A record to one server address. There is one server, so there is no failover address behind it. - A bare domain redirecting to www, or the reverse, is configured per project and is not a one-click setting. - Stackap is not a domain registrar and does not host email. ## Questions **Q: How long until HTTPS works?** As long as it takes your new DNS record to propagate, plus a short wait for the certificate. We have not measured a typical time because propagation depends on your provider and the record's cache lifetime. **Q: Can I move a live domain with no downtime?** Run the new site on its automatic address, compare it with the old one, and then change the single DNS record. Lowering the record's cache lifetime a day earlier makes the change land faster. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/environment-variables/ Product # Environment variables and secrets Stackap stores each environment variable encrypted and bound to its project and name, never shows the value back, and hands it to your app through a private file at start. ## What it does You set a variable with stackap env set KEY --stdin, and the value comes from standard input, so it never appears in a command line, a shell history or an agent's transcript. Setting the same key again replaces it. Removing one is env rm. Each value is encrypted with AES-256-GCM under the platform's master key, and the project and the variable name are bound into the encryption, so a stored value cannot be copied from one project or key to another and still decrypt. Listing variables returns the names and a mask, never the values. A few variables are managed by Stackap itself, such as the one carrying the database connection string. Those are flagged as system variables, and an attempt to change or delete one is refused with a clear message. ## How it works When a container starts, the values are written to a private file readable only by the process that launches it and passed to the container from there. They are not placed on a command line, where any process listing could read them. The audit log records that a variable was set or removed, with the key and never the value. Because values are read when a container starts, a changed value reaches the app on its next start or deploy. During a build the rule is different and deliberate: names beginning with NEXT_PUBLIC_ are passed through, because they are public by design, and every other value is replaced by a placeholder, so no secret is baked into an image layer. The master key The encryption is only as recoverable as the master key. If it is lost, every stored variable and every backup is unreadable. Keep a copy outside the server. ## In practice $ stackap env ls my-app $ stackap env set my-app API_KEY --stdin $ stackap env rm my-app OLD_KEY ## Early-access scope - You cannot read a value back. If you lose a secret, set a new one; there is no reveal button. - No per-environment or per-branch variables. A project has one set, and only the production branch builds. - Non-public values are placeholders at build time, so code that needs a real secret during a build does not work. - There is no history of past values and no scheduled rotation. - The master key is a single point of failure for recovery. ## Questions **Q: Can a teammate see my secrets?** Not through Stackap: values are masked in every listing. A person with root access to the server and the master key could decrypt them, which is true of any self-hosted system. **Q: Can I import a.env file?** There is no import command. Set each variable with env set. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/logs/ Product # Logs Stackap serves two logs for every project, the output of the latest build and the live output of the running app, both readable from one command or one API call. ## What it does The build log is everything the latest build printed, stored with that build: dependency installation, your build script, and Stackap's own lines such as which project type it detected and what it generated. It is the first place to look when a deploy does not go live. The runtime log is a live tail of what the running containers print. When a project runs several copies, it collects from every running copy. If no container is running, it falls back to the stored deployment events, so there is still something to read after a crash. Both are read the same way, by an agent or a person, with stackap logs --source build|runtime --limit N. The default is the 200 most recent lines and the maximum is 5,000. ## How it works Logs go through the same authentication as everything else, so a token only reads its own organization's projects. A project that belongs to someone else returns the same not-found response as one that does not exist. Container logs rotate at 10 MB with three files kept, which stops a chatty app from filling the disk. That setting applies to containers created after it was introduced, so a long-running older container keeps its previous behavior until it is next deployed. The usual loop for an agent is short: deploy, read the build log, change the code if the build failed, and read the runtime log if the build passed but the health check did not. ## In practice $ stackap logs my-app --source build $ stackap logs my-app --source runtime --limit 500 ## Early-access scope - Build logs are served for the latest build only. Older builds' logs are stored but are reachable through the API by build id, not through this command. - Runtime logs are a bounded tail, not an archive. Past the rotation limit, older lines are gone. - There is no search, no filtering by level and no streaming to an outside log service. - Database logs are not supported yet, and the API says so when asked. - Logs are not backed up. ## Questions **Q: Can I follow logs live?** The command returns the most recent lines each time you run it. It does not hold a connection open and stream. **Q: Where do request metrics go?** Not into logs. Request counts and load times are collected separately. See monitoring. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/monitoring/ Product # Monitoring Stackap runs a set of health checks on the server and every project, sends an alert when one fails, and records the load time of every project's requests. ## What it does These checks run continuously: host CPU, memory and disk, the Postgres server, running containers, database backups, repository backups, TLS certificates, recent deployments, and scheduled jobs. Each reports ok, warn or fail with a one-line detail, and the platform summarizes them as one overall state. When a check fails, an alert goes to a Telegram chat, and it repeats every six hours until the check is ok again, so a missed message is not a missed problem. The platform operator can read the current alerts through the API. Separately, every project gets load-time metrics. The web server in front of the apps writes an access log, which is turned into per-project request counts and a latency histogram, from which the median and slower percentiles are estimated. Ranges of one hour, 24 hours and seven days are available, and each deployment gets its own summary so you can see whether a release made things slower. ## How it works - The deployments check reports a failed build with the note that the previous deployment keeps serving. - The backups check goes red if any database has no recent, verified backup, and it includes the control plane's own database. - The certificates check reads the certificates actually served and warns as they approach expiry. - cron warns when some jobs are flaky and fails when some are down. Metrics are bucketed finely at the low end on purpose, because a fast app answers in a few milliseconds and coarse buckets made a fast app look slower than it was. Percentiles are estimates read from the histogram, not exact values. ## In practice $ stackap status # platform operators only GET /v1/projects/my-app/metrics?range=24h ## Early-access scope - The monitor runs on the same server it watches. A whole-server outage cannot alert you, so pair it with an outside uptime checker. No external probe is built in. - The host-wide status command and the alert list are for the platform operator only, because they name every tenant's projects. - Alerts go to one Telegram chat. Email and other channels are not built. - There are no custom metrics, no error tracking and no traces. - Latency figures are estimated from a histogram, and they describe requests as seen at the server, not what a visitor far away experiences. ## Questions **Q: Does it tell me when a deploy fails?** Yes. A failed build or an unhealthy deployment shows up in the deployments check and in the project's timeline, and the previous version keeps serving. **Q: Can I see load time in the dashboard?** Yes, per project, with a range selector. The same numbers are available from the metrics endpoint. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/rollbacks/ Product # Rollbacks A Stackap rollback re-activates the previous deployment with one command, health-checking it first, using the same switch a normal deploy uses. ## What it does After each successful deploy, Stackap keeps the previous version as a rollback target. If the new version turns out to be wrong in a way a health check cannot see, run stackap rollback . The previous deployment is re-activated, checked, and only then given traffic. A rollback is not a special emergency mode with its own risks. It is the ordinary swap from a deploy, pointed backwards. That means it inherits the safety of the forward path: if the older version will not start or fails its health check, routing does not change and the current version keeps serving. It is worth separating rollback from a different protection that is easy to confuse with it. A build that fails, or a container that is unhealthy, never goes live in the first place, so there is nothing to roll back. Rollback is for the case where the new version was healthy by every automated measure and was still the wrong version. ## How it works The sequence is short and every step is recorded in the audit log with who ran it: - You run the command for a project. Stackap looks up the previous deployment of that project. - It re-activates that deployment and polls its health endpoint until it answers or times out. - If healthy, the routing table is updated inside a database transaction and Caddy sends traffic to it. - If not healthy, nothing changes, and the command reports why. Tested the unpleasant way The deploy path was exercised with a deliberately broken release. The broken build never went live, the earlier version kept serving, and the failure was recorded. A system that only works when everything works is a demo, not a platform. ## In practice $ stackap deployments my-app # see what is available $ stackap rollback my-app # go back to the previous deployment $ stackap logs my-app --source runtime ## Early-access scope - Rollback restores application code only. It does not undo database changes or uploaded files. If the newer version ran a migration, the older code runs against the migrated schema, so keep migrations backward compatible or restore from a backup deliberately. - The command takes a project and goes to the previous deployment. There is no argument for choosing an older one. - A daily maintenance job removes build images beyond the newest three per project, so older builds are not kept around to roll back to. - There is no automatic rollback on a rising error rate. Rollback is a human or agent decision, not a reaction to metrics. - There is no gradual or percentage rollout. Traffic moves from one version to the other at once. ## Questions **Q: Does a rollback undo my database?** No. It swaps the running application only. Databases are protected separately by encrypted, restore-verified backups, which can be restored into a new database. **Q: How quickly does a rollback take effect?** As fast as the older version starts and passes its health check, followed by the routing change. We have not published a measured figure, so we do not quote one. **Q: Can an agent run it?** Yes. It is an ordinary CLI command and an HTTP API call, with no interactive prompt. See the CLI reference. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/scaling/ Product # Scaling Stackap scales an app by running several copies of it, from one to eight, on the same server behind a load balancer that sends each request to the least busy copy. ## What it does Scaling is a single call that sets the number of copies: PUT /v1/projects/:slug/scale with a number from 1 to 8. New copies start and pass their health check before any traffic reaches them, and a deploy requires every copy to be healthy before it counts as live. Requests are spread across copies by least-connections, and if one copy fails, the load balancer stops sending to it and carries on with the rest. A copy was killed in a test and no request failed. The reason this helps is mundane. A Node process uses one core, so one copy of a busy app leaves most of a four-core machine idle. Running more copies puts the idle cores to work. ## How it works Measured on one 4-CPU server serving a real site's pages, with 256 connections and no errors: Copies | Requests per second | 1 | about 426 | 2 | about 606 | 3 | about 683 | At three copies the server's load average peaked at 4.6 on four cores, so that is roughly where one machine tops out for that kind of page. A total cap on copies across all projects, set by the operator, stops one project from using the whole machine. ## Early-access scope - Scaling is for the platform operator only, because it spends capacity every project shares. A tenant cannot change its own count. - It is horizontal across cores on one machine. Spreading an app over several servers is not built. - There is no autoscaling. Nothing adds or removes copies in response to load. - Per-copy state is not shared: an app must keep sessions and caches in the database, not in memory, and Next.js's incremental cache is per server. - The throughput figures are for static-heavy pages from one test. Your app's numbers depend on its work per request. ## Questions **Q: Can I scale the database?** Not by this mechanism. Copies are for apps. There is one Postgres server, no read replica and no pooler yet. **Q: What is the next step beyond one server?** The plan is a load balancer with a stable address, the database on its own server, a job queue, and then several app servers. None of that is built, and it is a plan, not a date. Last updated 2026-10-03. --- Source: https://www.stackap.com/product/storage/ Product # Storage Stackap keeps uploaded files in a Cloudflare R2 bucket in your own account and serves them through the open-source Supabase storage service, so code written for that API keeps working. ## What it does Files live in an object-storage bucket you control, not on the server's disk, so a deploy or a rebuilt server does not lose them. The storage service in front of the bucket is the official open-source Supabase storage API, which means an app that already uploads and downloads through the standard client does not need new code. Buckets can be public or private, as they are in the original product. Public buckets give files a stable URL; private ones require a signed request. The bucket sits in your Cloudflare account, so the encryption keys, the billing and the delete button are yours. R2 does not charge for data leaving it, which keeps the cost of serving files predictable. ## How it works The first real use is a Next.js site. Its buckets held 93 objects. All 93 were downloaded, checksummed, uploaded to the new storage and verified one by one. Sixty URLs stored in database columns were then rewritten to point at the new storage host, and the sampled images loaded from it. The storage service is deployed by an operator script per project, and it uses the project's own database for its metadata. The metadata schema is included in the project's database backup, which has been restored and checked. ## Early-access scope - Only one project uses it so far, and it is set up by the operator with a script, not by a switch in the dashboard. - R2 is the single durable copy of your files. There is no second copy elsewhere, so if you need one, replicate the bucket yourself. - There is no content delivery network in front of file URLs, and the server is in Germany, so distant visitors see more latency. - Image transformations that the hosted product offers have not been enabled or tested. - The CLI has no storage commands. ## Questions **Q: Can I use the S3 API directly?** R2 itself speaks the S3 interface, and you hold its credentials in your own account. Stackap's own surface is the Supabase storage API in front of it. **Q: What if I want to leave?** The files are already in your bucket. Nothing needs to be exported, because Stackap never held them. Last updated 2026-10-03. --- Source: https://www.stackap.com/resources/ Resources # Resources Reading that explains how Stackap works and why, drawn from the pages in the other sections. Reading that explains how Stackap works and why, drawn from the pages in the other sections. Every page below states its limits. New guides are added here as they are written. ## Pages in this section - Deploy a Next.js app: How to deploy a Next.js app to a server you own: git push, public build variables, a custom domain and a one-command rollback. Step by step. - Deploy a Vite app: Step by step: deploy a Vite or Create React App single-page app to Stackap, with the index.html fallback, build-time variables and a custom domain. - Deploy a Node.js API: Step by step: deploy a Node.js API with a start script to Stackap, with the PORT contract, a health path, secrets and a database. - Deploy an Astro site: Step by step: deploy a static Astro site to Stackap, with real 404 pages, build-time image handling and the server-adapter caveat. - Deploy a React app: Step by step: deploy a React single-page app to Stackap, the router and base-path settings that matter, and how to tell Vite from Create React App. - Vercel and Supabase alternative: Stackap does the deploy half of Vercel and the Postgres and storage half of Supabase on one server you own. What it replaces, and what it does not. - Vercel vs Stackap: A factual comparison of Vercel and Stackap for deploying web apps: what each handles, who runs the servers, and where the trade-offs sit. - Supabase vs Stackap: A factual comparison of Supabase and Stackap for Postgres, storage and APIs: what each provides, what Stackap lacks, and when each is the better choice. - Vercel alternative: A Vercel alternative that runs on a server you own. Check what you rely on first: previews, edge and functions do not move; git deploys, cron and domains do. - Supabase alternative: A Supabase alternative for the data side: tables, rows, the data API and storage carry over; sign-in, realtime and edge functions do not. A feature checklist. - Railway alternative: A Railway alternative for a fixed server cost: one container and a private Postgres per project, with no multi-service canvas. What you give up. - Render alternative: A Render alternative for web services, static sites and cron jobs on a server you own: what maps across, what does not, and what a move involves. - Heroku alternative: A Heroku alternative with git-push deploys, Postgres and cron on your own server. Procfile and dynos versus containers; add-ons versus built-in services. - Railway vs Stackap: A direct comparison of Railway and Stackap on billing, project shape, databases, scaling and operations, written to say where each is the better pick. - Migrate from Vercel and Supabase: The steps, the inventory and the known gaps for moving an app from Vercel and Supabase onto Stackap, based on the first real move. - Migrate from Vercel: Moving an app from Vercel to Stackap when the database stays put: variables, crons, domain and the Vercel-only settings that need recreating. - Migrate from Supabase: Moving a Supabase database and storage onto Stackap: the tables and rows that copy, the functions that do not, and sign-in that blocks the move. - Migrate from Heroku: How to move a Heroku app to Stackap: map the Procfile to a start script, config vars to environment variables, Heroku Postgres to a project database. - Migrate from Render: How to move web services and static sites from Render to Stackap: environment groups, the Postgres dump, cron jobs, and the persistent disk question. - Migrate from Railway: How to move an app from Railway to Stackap: split a multi-service project, copy variables and the Postgres data, and handle private networking. Last updated 2026-10-03. --- Source: https://www.stackap.com/resources/faq/ Resources # Questions people ask These are the questions people ask about Stackap, answered with the limits stated alongside the strengths. Each answer says what is measured and what is planned. The early-access page lists what is included today and the scope of the platform. ## Questions **Q: What happens if the server dies?** Your sites are down until you restore, and restoring is built for it: databases and repositories are backed up daily to a bucket in a different company's cloud, encrypted, and restore-tested, and a restore onto a separate machine from only the bucket and the master key has been proven. A full rebuild drill on a fresh machine and a standby server are on the roadmap. **Q: Can I leave if I do not like it?** Yes, and that is a design goal. Your data is in standard Postgres that you can dump with ordinary tools. Your files are in your own bucket. Your applications are containers and plain git repositories. The Supabase-compatible layer means application code does not need to change on the way out any more than it did on the way in. **Q: Does it only work with Next.js?** No. Any application that can run in a Docker container works: give it a Dockerfile that listens on the port Stackap provides. Next.js is special only in that Stackap will generate the Dockerfile for you if you do not have one. This very page is a plain static site served by a small web server in a container. **Q: How compatible is it with Supabase?** For the parts we use, very. The data API is PostgREST, the same engine Supabase uses, and file storage is the official Supabase storage service. An application using the standard JavaScript client was tested against the kinds of queries a large production codebase makes. What it does not include is Supabase's authentication service, realtime subscriptions or edge functions; applications that depend on those would need work. **Q: Where does the server run?** Early access runs on a server in Germany. The location is a choice, not a constraint: visitors in North America see a little extra latency, and a server in the United States is a matter of provisioning another machine and restoring from backup. **Q: How long does a deploy take?** For the large Next.js site, the build was about 96 seconds, and the whole path from push to live was a couple of minutes. A static site like this one builds in a few seconds. **Q: Do I need to be a DevOps engineer?** You need to be comfortable with a terminal, SSH and DNS records. You do not need to hand-configure certificates, proxies, container networking or backup scripts, because those are the parts Stackap does. If you can follow a hosting provider's setup guide, you can run it. If you would rather not, the platform is also designed to be driven by an AI coding assistant. **Q: How are my secrets protected?** Environment variables and database connection strings are encrypted at rest and bound to their project and name. They are never shown back in plain text and are handed to containers through a private file rather than the command line. Access tokens are stored only as one-way hashes. The master key that unlocks everything lives outside the server's own database; if it is lost, encrypted variables and backups cannot be recovered, so keep a copy in a password manager. **Q: Can I use my own domain, including the bare one?** Yes. Attach the domain to a project, create the single DNS record Stackap shows you, and routing and the certificate switch on by themselves once DNS is correct. Lower the record's cache lifetime a day before any production switch. This site's bare domain redirects to the www address. **Q: How is Stackap priced?** Stackap is in invite-only early access, and terms are arranged with each team. See pricing for how that works, and ask for an invitation to start the conversation. **Q: Will Stackap do more than hosting?** That is the plan. Hosting comes first and is in early access today. A phone service and an email service are in development next, then financial services, so the operating side of a small business can live in one place that an agent can run. None of the three is available yet; the roadmap says what is planned and in what order. **Q: Is it open source? Can I get it?** Stackap is the founder's own software and is not publicly distributed yet. Access is by invitation while the remaining gaps are closed. If you are interested, the contact page says how to ask. **Q: How is it different from other self-hosted deployment tools?** Tools such as Coolify and Dokploy cover deploying applications and databases on your own server, and they are worth a look. Stackap's particular combination is the part that surrounds the deploy: Supabase-compatible data and storage layers, verified encrypted backups with restore testing, a built-in scheduler that imports vercel.json, and walled multi-tenant organizations. We have not benchmarked against them and do not claim to be better at what they do. **Q: Is it ready to use?** Stackap is in early access: it serves a real public website today and has passed the checks described in the proof section, and a limited number of teams are being invited with hands-on onboarding. It runs on one server, so whether it fits depends on what a bad hour of downtime would cost you. The early-access page lists exactly what is included. **Q: Can an AI agent operate it?** Yes, and it is how it was built. Everything the dashboard can do is an authenticated API call, the command-line tool wraps the same API, and output is plain text. That makes it straightforward for scripts and coding assistants to deploy, read logs, change variables and roll back. Last updated 2026-10-03. --- Source: https://www.stackap.com/resources/glossary/ Resources # Glossary These are the terms Stackap uses, in plain English. Where a term has its own page, the page gives the full detail. These entries are the short version, for readers and for language models that need one unambiguous definition of each word. **Control plane**: The part of Stackap that manages everything else: its API, its database of projects and settings, and its background workers. **Project**: One application, with its repository, domains, variables, database, schedules and backups. **Organization**: A group that owns projects, tokens and git keys, walled apart from every other organization. **Tenant**: One organization, seen from the point of view of a platform that serves several of them. **Health check**: A request Stackap makes to a new version before it receives visitors. It must answer successfully or the deploy is abandoned. **Approval**: A human decision for one risky action. The agent is stopped, the account owner gets a link by a separate channel, and approving covers only that exact request, once, within an hour. **Rollback**: Re-activating the previous version of a project, health-checked first. **TTL**: Time to live: how long other computers may remember a DNS answer. A long one slows down any change of server. **PostgREST**: Software that turns a Postgres database into a web API, used by Supabase and by Stackap. **R2**: Cloudflare's object storage, which Stackap uses for backups and uploaded files. It follows the S3 interface and does not charge for data leaving it. **Row-level security**: A Postgres feature that restricts which rows a database user may read or change, enforced by the database itself. **Point-in-time recovery**: Restoring a database to any chosen moment, not only to the last nightly backup. Planned, not built. **Master key**: The one secret from which Stackap's encryption keys derive. Lose it and every encrypted variable and backup is unrecoverable. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/ Solutions # Solutions Stackap suits people who run several conventional apps, work with a coding agent, and want to stop paying a stack of hosting bills. Stackap suits people who run several conventional apps, work with a coding agent, and want to stop paying a stack of hosting bills. Each page describes a situation, what Stackap offers for it, and who should wait. Where Stackap is a poor fit, the page says so. ## Pages in this section - AI app deployment: How to deploy an app built with a coding agent: the commands an agent runs on Stackap, what a person still approves, and where it falls short. - Vibe coding: For people building apps by directing an AI coding agent: how Stackap hosting fits, the terminal and DNS steps you still meet, and the safe habits to set. - Startups: Where Stackap fits an early-stage startup, where it does not, and the questions a customer security review will ask that it cannot yet answer. - Solo founders: How a solo founder running several products uses one Stackap server: one bill, one backup system, alerts to a phone, and the hours of upkeep it costs. - Agencies: How an agency can host several clients' apps on one Stackap server with separate organizations, and why tenant code is not yet sandboxed. - SaaS: What Stackap hosts for a multi-tenant SaaS, why tenant isolation inside your app stays your job, and the single-server limits that matter at scale. - Web apps: A map of the pieces of an ordinary web app, front end, API, database, files, cron and domain, to what Stackap provides and what you bring. - Production AI apps: What Stackap offers an app that calls model APIs: secret handling, logs, rollback and cron, and what it does not, such as GPUs, queues and long jobs. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/agencies/ Solutions # Stackap for agencies An agency can run its clients' apps on one Stackap server, with each client in its own organization whose projects, tokens and git keys the others cannot see or touch. ## The situation An agency usually carries a pile of small hosting accounts: one per client, each with its own bill, its own logins and its own way of being deployed. The cost is not only money. It is the time spent remembering where each client lives. Stackap's answer is to put them on one server with walls between them, so that the agency runs one platform and each client sees only their own work. ## What Stackap gives you here - Organizations. Each client is its own organization with an owner token, and every project, token and git key belongs to exactly one. - Per-organization git keys that can reach only that organization's repositories. - A single wall in the code that filters everything by the caller's organization, with a test that fails the build if any query skips it, and an attack suite of 43 cross-organization attempts that are all refused. - Identical responses for a resource in another organization and one that does not exist, so a client cannot learn what another client has called a project. - One backup system and one monitor for every client's app. ## How it looks in practice The operator, which is the agency, creates an organization for a client through the API and gives them an owner token, shown once. The client can then deploy their own projects, or the agency can do it for them. The agency keeps a platform-level view of health across all of them. The same design runs the founder's own multi-tenant CRM, which serves roughly a hundred businesses from one codebase. Stackap copies that approach rather than inventing one. ## Early-access fit Early access is a less natural fit if any client could be hostile. Tenant code is not sandboxed: each organization's apps run on the same machine, in containers with limits, but not inside a hardened sandbox. Organizations are therefore created only by the operator, for parties that are trusted. Early access is a less natural fit if clients expect to create organizations themselves. Organizations are created by the operator, through the dashboard, the API or the command line. ## Early-access scope - Tenant code is unsandboxed, so this suits trusted clients only. - Organizations are created by the operator; clients do not create their own. - A second, database-level lock (row-level security) beneath the application wall is planned, not built. - No independent security review has been done, and there are no compliance certifications. ## Questions **Q: Can clients create their own organizations?** No. Only the platform operator can create one, which is a deliberate limit while tenant code is unsandboxed. **Q: Does one client's heavy traffic affect another?** They share one machine, so it can. Containers have CPU, memory and process limits, and a project can run several copies, but there is no per-client performance guarantee. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/ai-app-deployment/ Solutions # AI app deployment Stackap lets a coding agent take an app from a repository to a live HTTPS domain with a handful of commands, without a person clicking through hosting dashboards. ## The situation Coding agents have made writing an application fast. The slow part has moved to everything after the code: creating accounts at several providers, copying keys between them, pointing domains, and diagnosing a failed deploy from screenshots and pasted logs. That is the gap this page is about. The agent can write the app and then has to stop and ask a person to go and configure something. Each of those stops is a place where the work goes back to a human for a reason that has nothing to do with judgment. ## What Stackap gives you here - A command-line tool and an HTTP API for every operation in the loop: create a project, set variables, deploy, read logs, add a domain, roll back. - Secrets passed on standard input, so an agent never has to put one on a command line or in a transcript. - Build and runtime logs readable by the same tool, so the agent inspects a failure instead of asking you to describe it. - Health-checked deploys that cannot take a working site down, which makes it safer to let an agent deploy without supervision. - A site summary in plain text at /llms.txt, generated from the same pages people read. ## How it looks in practice The whole path, once a Stackap server and token exist, is short. The agent logs in, creates the project, sets variables, deploys and reads the build log. If the build fails, the log says why, and the agent changes the code and deploys again. Attaching a real domain adds one step that is not automated: a DNS record, which a person or an agent with DNS access creates at the DNS provider. What a person still decides is what the agent should not decide alone: whether to deploy to production, which domain to use, whether a rollback is warranted, and when to approve anything destructive. $ stackap create my-app --name "My App" $ stackap env set my-app DATABASE_URL --stdin $ stackap deploy my-app $ stackap logs my-app --source build $ stackap domains add my-app www.example.com ## Early-access fit If you need one-click sign-up, you should wait: Stackap is invite-only, and an account or organization is created by the operator. If your app needs sign-in, previews on every branch or a global edge network, it will miss them. See the comparison. ## Early-access scope - There is no sign-up flow. An agent cannot create its own account. - There is no dedicated tool-protocol server, only the command-line tool and the HTTP API. - Domains need a DNS edit that Stackap does not make. - Nothing here has been measured against a list of named agents; the claim is only that anything able to run a command can use it. ## Questions **Q: Does it work with Claude Code or Codex?** Anything that can run a shell command can use the command-line tool, so it should. We have not run a formal test against a list of products, so we do not publish one. **Q: Is it safe to let an agent deploy?** A deploy cannot take a working site down, because the old version keeps serving until the new one is healthy, and rollback is one command. It cannot undo database changes, so keep a human in the loop for anything destructive. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/production-ai-apps/ Solutions # Stackap for production AI apps Stackap hosts the application around a model, its web app, API keys, database and scheduled jobs, but it does not host models, GPUs or background workers. ## The situation An AI app, in the sense most people mean, is an ordinary web app that calls a model provider's API. The model runs elsewhere. What you need from hosting is what any app needs, plus extra care for the API keys, which are the most expensive secrets you hold. That is the part Stackap covers. If you mean running models yourself, on your own GPUs, this is the wrong platform. ## What Stackap gives you here - Encrypted, masked storage for provider API keys, set from standard input so they never reach a transcript or a shell history. - Build-time protection: non-public values are placeholders during the build, so a key is never baked into an image. - Runtime and build logs your agent or you can read to see why a request failed. - Rollback, for the day a prompt or model change makes the app worse. - Cron jobs for scheduled work such as evaluations, digests or clean-up. - A Postgres database for conversations, results and usage records. ## How it looks in practice Keep each provider key in its own variable, rotate by setting a new value, and give development and production different keys. Log what you need to debug a failure but not the raw prompts of your users. Treat cost as an application concern. Stackap shows request counts and load time, not spend per provider, so record token usage in your own database. ## Early-access fit Early access is a less natural fit if you need GPUs, or to run open models yourself. Stackap runs ordinary containers on one CPU server. Early access is a less natural fit if your work arrives as jobs that run for minutes with no web request. A worker needs an HTTP port to pass the health check, and there is no queue. ## Early-access scope - No GPUs and no model hosting. - No queue and no background workers without an HTTP port. - Very long or streaming responses have not been tested end to end through the proxy, so test yours. - No usage or spend tracking for providers. ## Questions **Q: Where should my keys live?** In environment variables set from standard input. Public prefixed variables are readable by every visitor, so never put a provider key in one. **Q: Can a request run for a long time?** Stackap runs your app as an ordinary container, not as short serverless functions, but we have not measured limits on long or streaming responses, so test the longest one you will serve. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/saas/ Solutions # Stackap for SaaS products Stackap can host a multi-tenant SaaS app and its database, but the isolation between your customers inside the app is still your code's job, not the platform's. ## The situation There are two different meanings of multi-tenant here, and they are worth separating. Stackap itself is multi-tenant: it keeps different organizations' projects, tokens and keys apart from each other. A SaaS product is multi-tenant in a second way, keeping its own customers' data apart inside one app and one database. Stackap provides the first and cannot provide the second. Your customers all live behind one project, as far as the platform can tell. ## What Stackap gives you here - A project and a private Postgres database for the app, with a role that reaches nothing else. - The pattern for tenant isolation used by the founder's own CRM, which serves about a hundred businesses from one codebase: a customer identifier on every row and one place in the code that filters by it. It is a reference, not a feature you switch on. - Scheduled jobs, storage and backups for the app. - Separate organizations on Stackap, if you want a customer's dedicated environment walled off from the rest. ## How it looks in practice The app's own isolation is the part that deserves the most testing. The founder's approach is a single wall module that every query goes through, a static check that fails the build if any query skips it, and a suite of attack tests. The same discipline protects Stackap's own organizations, with 43 cross-organization attempts all refused. On the hosting side, plan for a staging project with its own database, a backup you have restored at least once, and cron jobs written to be safe to call twice. ## Early-access fit Early access is a less natural fit if you need recovery to a moment in time. A SaaS can lose a customer's work in a day, and daily backups with no point-in-time recovery are a real step down from a hosted database. Early access is a less natural fit if you need a high-availability or multi-region story for contracts. One server in one region is what exists. ## Early-access scope - Stackap does not isolate your customers from each other; your app does. - No point-in-time recovery, no standby, one region. - A second, database-level lock such as row-level security is something your app can use in Postgres, but the platform does not set it up for you. - No compliance certifications. ## Questions **Q: Does Stackap give each of my customers a database?** Only if you create a project for each, which is not designed for thousands of tenants. The usual SaaS pattern is one database with a tenant column. **Q: Where is the tenant-isolation pattern written down?** The security page describes the wall, the static check and the attack tests used for Stackap's organizations; the CRM uses the same approach. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/solo-founders/ Solutions # Stackap for solo founders A solo founder who runs several products can put them on one Stackap server with one bill and one backup system, in exchange for becoming the person who operates that server. ## The situation Stackap came out of exactly this situation. The founder runs a handful of products, one of them a multi-tenant CRM serving about a hundred businesses, and the hosting for them was spread across several vendors. Alone, the cost of that sprawl is not mainly money. It is attention. Every product has its own dashboards, its own keys and its own way of failing, and you are the only one who knows where they are. ## What Stackap gives you here - One server hosting every product, with each in its own project and its own database. - One place to look for health, with alerts sent to a Telegram chat on your phone. - One backup system with a visible record of when each database last proved it restores. - A command to roll back a bad release at any hour without opening a laptop full of dashboards. ## How it looks in practice The founder's current sites run on one four-core, eight-gigabyte server, with storage and backups in a bucket he owns. The routine is light but real: glance at the status when an alert arrives, keep the master key somewhere safe, and keep the server's operating system updated. ## Early-access fit Early access is a less natural fit if you cannot afford a bad evening. With one person, an outage at night is yours alone, and there is no standby server to fail over to. Early access is a less natural fit if one of your products is large enough to need its own machine. Putting everything on one server means a busy product slows the others. ## Early-access scope - Early access is run by the founder directly, so you work with the person who builds it. - The monitor runs on the server it watches, so a total outage cannot alert you. Add an outside uptime check. - Everything shares one machine's four cores and eight gigabytes. - Recovery from a total loss of the server has not been tested end to end. ## Questions **Q: How many apps fit on one server?** It depends on what they do. Static sites cost almost nothing, and a busy Node app can use a whole core, so count by load and not by number. **Q: Do I need to be a DevOps engineer?** You need to be comfortable with a terminal and DNS. You do not need to configure certificates, proxies or backup scripts by hand. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/startups/ Solutions # Stackap for early-stage startups Stackap suits an early-stage startup whose product is a conventional web app and whose hosting bill is starting to matter, and it does not suit one that needs compliance paperwork or global delivery this quarter. ## The situation A startup's hosting bill rarely starts large, which is why it is easy to ignore. The problem is the slope: each new service adds a plan, and usage-based pricing means a good month for the product is also a more expensive month for the bill. There is a second, quieter cost. The more places your product lives, the more places a new engineer has to learn, and the more accounts someone has to remember to offboard. ## What Stackap gives you here - A flat cost: a server and a few dollars, not a set of meters. - Everything in one place, which shortens the list of systems a new engineer has to learn. - Encrypted backups to a bucket in your own account, restore-tested weekly. - Walled organizations, in case you later host a customer's environment next to your own. - Standard Postgres and ordinary containers, so leaving costs a copy, not a rewrite. ## How it looks in practice The practical shape is a staging project and a production project on the same server, each with its own database. Releases are a push, a health check and a switch. Alerts go to a chat. Backups run on their own and you can see when they last proved they restore. The cost to budget for is your own time. Someone owns the server: applying updates, reading alerts and deciding what to do in an incident. For a team of two with a comfortable terminal user, that is a small, steady cost. For a team with no one who wants it, it is not. ## Early-access fit If an enterprise customer will send you a security questionnaire next month, hold off: independent penetration testing and compliance certifications are not part of early access. Early access is a less natural fit if you need high availability. Early access runs on one server; a full rebuild drill and a standby server are on the roadmap. ## Early-access scope - Independent security review and certifications are not part of early access. - One server, one region, no standby. - Early access is run by the founder directly, which is also why onboarding is hands-on. - Backups are daily with no point-in-time recovery. ## Questions **Q: Can we run production on it?** The founder's own public site runs on it. Whether that is enough for you depends on what an hour of downtime costs you. **Q: Is there a team plan?** There is no plan structure yet. See pricing. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/vibe-coding/ Solutions # Hosting for vibe-coded apps If you build an app by directing a coding agent rather than writing the code, Stackap gives the agent a place to put it in production, though a few steps still need you, and being honest about them is the point of this page. ## The situation The experience of building this way is that the app appears quickly and then stalls at deployment. The agent writes working code, and then the conversation turns into a list of accounts to create and settings to find. Each item is small, and together they are where most first projects stop. Stackap tries to shorten that list. It cannot make it empty, and a page that promised that would be setting you up to be surprised. ## What Stackap gives you here - One place that holds the repository, the build, the database, the files and the domain, so there are fewer accounts to create. - Commands your agent can run itself, with logs it can read when something fails. - A deploy that cannot break a working site, and one command to go back. - Secrets taken from standard input, so an agent can set them without you pasting them into a chat. ## How it looks in practice You describe what you want, the agent builds it, and the agent runs the deploy commands. If the build fails, it reads the build log and fixes its own mistake. You are asked to do only what needs a person: approve going live, and create one DNS record when you attach a domain. Three habits make this safer. Keep secrets out of the conversation: tell the agent to set them from standard input, and set the sensitive ones yourself. Ask the agent to show you the build log before it says a deploy worked. And keep the old version around until you have looked at the new one in a browser. $ stackap deploy my-app $ stackap logs my-app --source build $ stackap rollback my-app # if the new version looks wrong ## Early-access fit Early access is a less natural fit if you have never opened a terminal. Stackap expects you or your agent to run commands, and the DNS step is made at a registrar, not in a friendly form. If you can follow a hosting provider's setup guide, you can do it. Early access is a less natural fit if your app has user accounts through a hosted sign-in service, since Stackap has none, or if you need to accept payments with strict compliance needs on day one. ## Early-access scope - Stackap is invite-only, so you cannot sign up tonight. - You still need a terminal and a DNS record. - The platform checks that an app is healthy, not that it is correct. An agent can deploy a broken but healthy app. - There is no per-branch preview, so review the change before you push to production. ## Questions **Q: Will my agent know how to use it?** It can read the plain-text site summary and the CLI reference. We have not tested a list of agents, so we do not publish one. **Q: What if the agent makes a mistake?** A bad build never goes live, and a bad release is one rollback away. Database changes are different: they are not undone by a rollback, so back up before anything destructive. Last updated 2026-10-03. --- Source: https://www.stackap.com/solutions/web-apps/ 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 **Q: Can I run a Redis or a queue?** Not as a built-in service. A job queue on top of Postgres is a planned direction, not something built. **Q: Can the front end and API share a domain?** Each project has its own hostname. Sharing one hostname across two projects is not a feature. Last updated 2026-10-03.