How apps run
What happens to an app after your agent deploys it: who can reach it, how long work can take, redeploys, data, and moving an app. These are the questions teams ask before they move real work onto spawnpoint.
Who can reach an app
Every app starts private. A private app checks every request: a browser with no signed-in viewer gets the sign-in page, and a program gets a 401 that says where to sign in. There is no way yet to leave one path of a private app open, so a webhook sent from another server, such as a Slack event or a HubSpot webhook, cannot reach a private app. A sign-in redirect that comes back through the viewer's own browser, such as a Google or Microsoft OAuth callback, does pass, because that browser carries the viewer's spawnpoint sign-in.
An app that receives webhooks, or that your customers use with accounts of their own, should be public with its own sign-in. A public app may keep other people's personal data behind that sign-in, such as a customer portal, as section 6 of the terms describes.
spawnpoint decides who can open an app, but it does not tell the app who each viewer is. So an app shared with your team needs no login of its own, and an app that must know who each person is, such as a client portal where each client sees only their own records, needs a sign-in of its own. We recommend Auth0, which has quickstarts for Express, Next.js, Python, and React. Keep its keys in the app's environment variables, not in its files.
Long requests
spawnpoint's gate keeps a single request open for up to an hour, and in our tests a request held open for 5.5 minutes completed. Browsers and other proxies often give up much sooner, so for work that takes more than a minute, answer the request right away, do the work in the background, and have the page check back for the result.
Sleep and always on
An app on a machine sleeps after an hour with no visitors, and the next visit wakes it in about 30 seconds. A static site never sleeps. An always-on app never sleeps: Pro includes 5, Business 20, and Free none. Your agent turns it on with set_always_on.
Background and scheduled work
An always-on app can run background work with no time limit. That work shares the machine's CPU and memory with the app's web server: today each app's machine has 2 CPUs and about 4 GB of memory. spawnpoint has no separate worker process and no built-in scheduler yet, so scheduled work runs inside the app: node-cron or setInterval in Node, APScheduler in Python, next to a web server that answers on PORT. Keep a scheduled app always on, because a sleeping app's schedule stops.
Redeploys and failed deploys
Deploying again updates the app at the same link. The deploy stops the running version, then installs, builds, and starts the new one, so the app does not answer in between: about 12 seconds for a small Node app in our tests, longer when the install or build is slow. If the install, the build, or the start fails, the previous version is put back and started again, which in our test took about a minute end to end.
When it is stopped, on a redeploy or a restart, the app receives SIGTERM and has 90 seconds to finish before it is killed. Work that can take longer should save its progress and resume, and should be safe to run twice.
Database migrations
In a Node app, the build script in package.json runs after the install and before the new version starts, with the app's environment, including DATABASE_URL. A migration in that script runs after the previous version stops and before the new one starts. Keep each migration compatible with the previous version: a migration runs even when the deploy then fails, and the previous version is started again on the migrated database. A Python app can run its migrations at startup, before its server listens.
Releasing to many apps
An API token can belong to a team, and one team token deploys to every app on that team, one deploy per app. To make one, pick the team under Deploys as in the console's API tokens panel. A script can release the same code to several apps that way. Tokens expire after 30, 90, or 365 days, chosen when you create them.
Outbound calls
spawnpoint does not limit an app's calls to other services, such as Slack, Google, Microsoft, HubSpot, Salesforce, or Anthropic. Only those services' own rate limits apply.
What persists
Each app with a server has a data directory, named in SPAWNPOINT_DATA_DIR, that survives redeploys and sleep. It belongs to the machine: if the app's machine is replaced, for example when its runtime changes, the new machine starts with an empty one. A managed database lives on a separate database server and survives redeploys and machine changes.
Backups and restore
The database server keeps automatic backups for 7 days and can be restored to any moment in them, as a whole server. A database you remove is kept for 7 days, and its owner can restore it from the console. Restoring one app's database to an earlier moment is not available yet, so an app that needs that should export its own database on a schedule, for example a nightly pg_dump to its storage bucket.
The protect switch in the console stops agents from terminating a project or removing its database or storage until you turn it off.
Moving an app to another account
A personal app can move into your team. An app cannot yet move from one account to another, for example to a client's own account. To move one, export its database with pg_dump, copy its stored files, deploy the same code under the other account, restore the dump into the new app's database, and point any custom domain at the new app. An agent can do each step.
AI on open models
An app that uses AI on open models through spawnpoint sends each request through spawnpoint to OpenRelay, which runs the models on its own network of GPU capacity, including capacity from providers it works with. OpenRelay does not publish where a given request runs. spawnpoint does not store the requests or the answers: for each call it records the project, the model, the tokens in and out, the cost, and the time. OpenRelay's privacy policy says it collects the content of requests and responses, keeps information while our account with it is active or as long as it needs to provide its service, and may make de-identified data from them. For data that must not go to a third party on those terms, have the app call a model provider with its own key and a data retention agreement instead.
Building apps for clients
Consultants and agencies can build apps for their clients, charge them for those apps, and run them on their own account, under their own brand or a client's. The clients never need a spawnpoint account. What needs our written permission is reselling spawnpoint itself, such as selling spawnpoint accounts, as section 7 of the terms says.
Plans
How many apps stay always on, and how large databases and storage can grow, depends on the plan. The pricing page compares them.
Security reviews
The security page covers encryption, backups, who can reach your data, and where it lives. Our data processing agreement is published, and we countersign a copy on request. We answer security questionnaires: email support@getspawnpoint.com. spawnpoint has not had a SOC 2 audit yet.