Legal

Privacy Policy

This policy explains how spawnpoint handles your personal data.

Effective: August 8, 2026. Last updated: November 13, 2026.

1. Who we are

spawnpoint Inc. ("spawnpoint", "we", "us") runs the service at getspawnpoint.com and app.getspawnpoint.com: a console, an MCP server that AI agents deploy through, and the machines your projects run on. This policy covers all of it. Our Terms of Service govern the rest of the relationship.

spawnpoint Inc. is the controller of your account data: what this policy describes about you as someone who uses spawnpoint. For the personal data your deployed apps hold about their own users, you are the controller, and we process it on your behalf, only to run your app (section 6).

For questions, requests, or complaints, email support@getspawnpoint.com, and we will answer.

2. What we collect

Your email address. It is the only thing you tell us about yourself, and it is your account identity. We accept it only after our sign-in provider confirms it is verified.

Your projects. For each project you deploy: the name you chose, its status, runtime, entry point, the identifier and public URL of the machine it runs on, timestamps, health check results, and the output of the deploy itself (the last deploy's console output, capped in size, so a failed deploy is diagnosable). The machine reports what it is when a deploy finishes (installed runtime versions, CPU count, memory, kernel), and we keep that so the console can show it. We also record the machine's hourly cost to us, which we use to watch our own spending and never to bill you. Once a minute we fetch your app's public page to check it is up, and if that page carries an og:image tag we use that image as the project's thumbnail in the console. Runtime logs are read from your machine when you ask for them and are not stored by us.

Your environment variables. If you set variables on a project, we store them so a redeploy keeps them. Values are encrypted at rest with a key that lives on the control plane, are shown to nobody after being set (the console lists names only), and are pushed to your machine on each deploy. Whoever controls the control plane can read them. They are deleted when you terminate the project.

Your files, in transit. The files your agent deploys pass through us on the way to your machine. When an agent uploads a bundle separately from the deploy request, we hold it for at most 30 minutes and delete it the moment it is used. We do not keep a copy of your code on the control plane after it is pushed: it lives on your machine, which you can destroy at any time.

Credentials, hashed. API tokens and OAuth tokens are stored only as SHA-256 hashes, alongside a short display prefix. We cannot recover a token for you, only issue a new one.

Subscription records. Your plan (Free or paid), and if you subscribe, the customer and subscription identifiers our payment processor issues. Invoices and receipts live with the processor, not with us. See section 4.

Sharing lists. If you restrict a project to specific people, we store the email addresses you listed. We also record, per project, which of those addresses opened it, when they first and last did, and how many times. That log exists so you can see who used a link you shared.

Custom domains. If you point your own domain at a project, we store the domain name, the verification token we asked you to publish in DNS, and the result of our DNS checks. Verifying means we look up your domain's records; we store the outcome, not the records.

When your app was last visited. For a project reached through its share link, we record the time of the most recent request, to the nearest minute, so an idle project can be put to sleep and woken on the next visit. It does not record who visited.

Technical logs. Our servers log each request: method, path, response status, size, duration, and the caller's IP address. We use these logs for debugging and for investigating abuse.

AI on open models. When an app uses AI on open models through spawnpoint, its requests and the model's answers pass through our server to Amazon Bedrock, which Amazon Web Services runs in the us-west-2 region (Oregon). We do not store the requests or the answers, and our account is set so that Amazon Web Services does not store them either (section 7). For each call we record the project, the model, how many tokens went in and came out, the cost, and the time, to count usage against the plan.

Embeddings. When an app uses spawnpoint's embedding model (Cohere Embed Multilingual v3), which turns text into numbers so an app can search it, the text passes through our server to Amazon Bedrock in the same region, under the same zero data retention as the other models. We do not store the text or the results, only the same usage record for each call.

Traffic counts on our own site. Our pages call a one-pixel beacon that records the page, the referring domain, and a visitor identifier. That identifier is a one-way hash of a secret, the UTC date, and your IP address. The raw IP is never written down, the same person counts once per day, and because the date is inside the hash, two days of counts cannot be linked to each other. If you came through one of our own links that carries a tag, such as the "Start free" link under a spawnpoint app's sign-in page or in an invitation email, the beacon also records which link it was: one of a list of five tags, never anything else from the address.

3. What we do not collect

Card numbers. Payment pages are hosted by Stripe. Card details never reach our servers, and there is no payment form anywhere in our code.
Passwords. Sign-in is passwordless, so there is no password to store or leak.
Advertising or cross-site tracking. We use no ad networks, no third party analytics, and no tracking pixels other than our own first party counter described above. We do not build profiles or use fingerprinting. The daily visitor key described in section 6 is not one: it is different for each day and each project, we do not use it to link visits across days or projects, and once its day's random value is erased from our live database, shortly after the UTC day ends, it cannot be recomputed (backups keep the random value for a limited time, as section 6 says).
Your code, for our own purposes. We do not read, mine, sell, or license your projects, and we do not use your code, files, or prompts to train AI models.

4. Payments

Paid plans are a monthly subscription processed by Stripe. When you upgrade, you are sent to a checkout page Stripe hosts, and you give your card details to Stripe, not to us. Stripe tells us that your subscription started, changed, or ended, and we set your plan accordingly. Invoices, receipts, card changes, and cancellation all happen in Stripe's billing portal, which the console links to.

What we store is a Stripe customer identifier and a subscription identifier for your account, plus the plan itself. We hold no balance, no ledger, and no payment history of our own. What Stripe stores is governed by Stripe's privacy policy. Stripe is an independent controller of the payment data it holds, including any name, billing address, or card details you give it.

5. Cookies

We set four cookies, all of them strictly functional. There are no advertising or analytics cookies, so we do not show a consent banner.

__Host-sp_session: your console sign-in, as a signed token. There is no session table; we check the cookie's signature instead. HTTP-only.
__Host-sp_auth_state: set when you request a sign-in link and consumed when you click it. It is a security control: it ties the emailed link to the browser that asked for it.
__Host-sp_viewer: set on a share hostname after someone verifies their email to view a restricted project. Scoped to that one share origin.
__Host-sp_token_reveal: set for 2 minutes when you create an API token in the console, so the console can show the new token to you once. HTTP-only.

The __Host- prefix tells your browser to accept each cookie only from the exact host that set it, and only over HTTPS. No other site, including an app someone has deployed on spawnpoint, can set or overwrite them.

Deployed apps are yours: any cookie your own app sets is your responsibility, not ours.

6. Deployed apps and the people who visit them

Your projects run on machines we run for you on Amazon Web Services, and they are reachable at a public URL. This has two consequences:

You are responsible for what your app collects. If your deployed app gathers personal data from its visitors, you are the controller of that data and you need your own privacy notice for it. We process it on your behalf, only to run your app. We run the app, but we do not inspect its traffic or log what happens inside it. The one exception is the visit counts below: when a browser loads a page without signing in, we read the request's IP address, browser name, and referring address to count it, and keep only what the next paragraphs say.
Anything anyone with the link can read is public. That means a public project's pages and files, and any file in a public bucket. Do not put other people's personal data or secrets there. A public project may keep personal data behind a sign-in of its own, and you are responsible for that sign-in and for protecting what is behind it.

For restricted projects, viewers verify their email address through our sign-in provider before they can open the project. We store that address on the project's access log so the project's owner can see who opened it. That includes people let in because the owner shared the project with their whole email domain. Section 9 says how long the log keeps an entry.

When someone opens a page of a project without signing in (any page of a public project, or a page a restricted project lets anyone open), we count it so the project's owner can see how many people came and from where. For each page a browser loads, we record the day, a visitor key, and the domain of the site that linked to the page, never that site's page or the rest of its address. The visitor key is a one-way hash of the visitor's IP address, their browser's name, the project, and a random value we make each day, so one browser counts about once a day and cannot be followed from one project or one day to the next. The count is approximate: people sharing an address and a browser count as one, and one person on two devices counts twice. This counting writes down neither the IP address nor the browser name. The keys and the day's random value are deleted from our database a few minutes after the day ends (UTC), and leave our routine backups within 60 days; after that, nothing links a count to a person. The one exception is a final copy of the whole database that would be kept if the database itself were ever shut down, which holds everything in it at that moment. Requests from crawlers, link previews, and scripts are not counted. The owner sees only the totals: page views and visitors per day, and the referring domains.

Our Data Processing Addendum sets out how we process the personal data your apps hold on your behalf: our security measures, our sub-processors, breach notice, deletion, audits, and transfers out of Europe and the UK.

7. Who else sees your data

We do not sell personal data, and we have never disclosed it for money or for anyone else's advertising. We share it only with the providers we need to run the service:

Auth0 (Okta): sign-in; it sends sign-in emails through Amazon Web Services (Amazon SES). Receives your email address and sends the link or code. If you sign in with Google, Google confirms your email address to Auth0, and we receive only that verified address. Also used to verify viewers of restricted projects.
Stripe: subscriptions, as described in section 4.
SendGrid (Twilio): an older sender for the emails we send ourselves, kept as a fallback to Amazon SES. When it is used, it receives the recipient address and the message.
OpenRelay: no longer receives model requests. It ran the chat models until November 10, 2026, and the embedding model (bge-m3) until November 13, 2026, when both moved to Amazon Bedrock (see Amazon Web Services, below), so model requests and answers an app sent before then, and text it sent for embeddings, passed through OpenRelay. What it collected is held under OpenRelay's privacy policy, which lets it make de-identified data from the requests it handled. OpenRelay does not run the machines your projects run on: since November 6, 2026, those run on Amazon Web Services.
Amazon Web Services: hosts the control plane, its database, and the machines your projects run on, in the United States (the us-west-2 region, in Oregon). Our database, its backups, our logs, your deployed files, your environment variables, and your apps' databases and file storage sit on infrastructure they operate. The Amazon Web Services services we use are covered by their SOC 1, SOC 2, and SOC 3 reports (see our security page). It also sends the emails we send ourselves (Amazon SES), which today means share invitations, and so receives the recipient address and the message. It also runs the open models an app can use through spawnpoint, chat and embeddings (Amazon Bedrock), in the same region and no other, so an app's model requests and the answers pass through it. Our account is set to zero data retention for Amazon Bedrock, so Amazon Web Services keeps no requests or answers, does not use them to train models, and does not share them with the companies that make the models.
GitHub: serves the marketing site at getspawnpoint.com. Before we moved to Amazon Web Services, each deploy of the control plane also stored a compressed copy of our database there for 30 days; the last of those copies expire 30 days after the move.
Discord: when an account is created, we may post a message carrying the new email address to our own team chat so we know someone signed up. Nothing else goes there.
Google Fonts: our pages load a web font from Google's servers, which means Google receives the IP address of anyone loading one of our pages.

We may also disclose data if the law requires it, or where we reasonably need to in order to investigate abuse, enforce our Terms, or protect someone's safety. If we are ever compelled to hand over your data, we will tell you unless we are legally prohibited from doing so.

If the business is ever sold or merged, account data may transfer with it. You will be told before that happens.

8. Where your data lives

Our control plane and the machines your projects run on are in the United States, in the us-west-2 region (Oregon), and our database and logs sit there. Requests an app sends to open models, chat and embeddings, go to Amazon Bedrock in the same region, and are not sent to any other region. Our other providers operate globally. If you are in the UK, the EEA, or Switzerland, using the service means your data is transferred to the United States, and we rely on the standard contractual clauses our providers offer for those transfers.

9. How long we keep things

Account and project records: until you delete your account. Terminated projects stay on record (name, dates, and the last deploy output) as the history of what your account did; their machines and files are gone the moment you terminate.
Backups: Amazon Web Services keeps automatic daily backups of the database for 7 days. A copy taken each day and a copy taken before each deploy are stored in a separate storage bucket for 30 days, then held in that bucket's version history for 30 more before they are deleted. The host's disk is snapshotted daily and each snapshot is kept for 7 days. Deleted data leaves those on the same schedule.
App databases: a database you remove, or the database of a project you terminate, is kept for 7 days so you can restore it from the console, then deleted.
Uploaded deploy bundles: 30 minutes at most, and deleted immediately once used.
Visit counts for projects: the daily page views, visitors, and referring domains are deleted when you terminate the project, and otherwise after 90 days. The visitor keys behind a day's count are deleted a few minutes after that day ends, and leave our routine backups within 60 days.
Sharing lists and access logs: the addresses you shared a project with, and its record of who opened it, are deleted when you terminate the project. While the project runs, a person's entry in that record is deleted 90 days after they last opened it.
Deploy records (which account deployed and when, used for the hourly deploy limit and for our own usage counts): 30 days, then pruned.
Sign-in and agent tokens: authorization codes for 5 minutes, agent access tokens for an hour, refresh tokens for 30 days, all as hashes, and an agent has to sign in again 90 days after it first connected; API tokens until they expire (30, 90, or 365 days, chosen when one is made) or you revoke them. A connection an agent started but never finished is deleted after 3 days.
Subscription records: kept as long as tax and accounting law requires, which is longer than your account. Stripe keeps the invoices.
AI usage records (the project, model, tokens in and out, cost, and time of each call; never the request or the answer): until you delete your account.
Server logs: kept on the host for debugging and abuse investigation, and rotated off on the host's normal schedule.
Traffic counts: kept as daily aggregates for 400 days, then pruned. They contain no raw IP address and cannot be tied back to a person.

10. How we protect it

Everything is served over TLS. Tokens and credentials are stored only as hashes. Deployed apps are served from a different origin than the console. The console's cookies are host-only, so no deployed app can read, set, or overwrite them; the console refuses any request that changes something unless it comes from the console's own pages, and other sites cannot embed it in a frame. Our OAuth implementation requires PKCE, treats authorization codes as single use, and revokes an entire grant family when one is replayed. Payment webhooks are rejected unless they carry a valid signature over the exact bytes sent. The security page describes encryption at rest, backups, and who can reach your data.

No system is perfectly secure, and we are early software. If you find a vulnerability, please tell us at support@getspawnpoint.com before telling anyone else, and we will work with you.

11. Your rights

Wherever you live, you can ask us to:

Tell you what we hold about you, and give you a copy.
Correct anything that is wrong.
Delete your account and the data attached to it.
Stop processing your data, or object to a particular use.

Email support@getspawnpoint.com and we will act on your request within 30 days. We will not charge you, and we will not treat you differently for asking.

Deleting your account destroys your running machines and their contents, which cannot be undone. Some records survive deletion where the law requires it, subscription records in particular, and copies remain in backups for up to 60 days (section 9).

If you are in the UK or the EEA, our legal bases are: performing our contract with you (running your account, your deploys, and your payments), our legitimate interests (keeping the service secure, investigating abuse, and counting traffic in a way that identifies nobody), and compliance with legal obligations (tax records). You have the right to complain to your local data protection authority. If you are in California, we do not sell or share personal information as those terms are defined by the CCPA, and the rights above cover the ones it grants you.

12. Children

spawnpoint is not for children under 13, and we do not knowingly collect their data. If you believe a child has given us personal data, email us and we will delete it.

13. Changes to this policy

We will update this policy as the service changes. If a change is material, we will give reasonable notice by email or in the console before it takes effect, and the date at the top of this page will move. Continuing to use the service after that means you accept the updated policy.

14. Contact

Anything at all, including data requests: support@getspawnpoint.com.

Plain English summary. We know your email address, what you deployed, and which plan you are on. Stripe holds your card details and invoices; we do not. Environment variables you set are encrypted at rest but readable by us. We do not sell anything, run ad trackers, or train models on your code. Our traffic counter never stores your IP address, only a hash of it that changes every day. Ask us for your data or for deletion and you get it. This summary is not the policy, the sections above are.