Privacy Policy

What we collect, why we collect it, who else sees it, and how long we keep it. This describes what the software actually does, not what a template says it might.

Effective: August 8, 2026. Last updated: September 28, 2026.

1. Who we are

spawnpoint ("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.

For questions, requests, or complaints, email founders@getspawnpoint.com. We 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. Treat them as secrets we hold for you, not as a vault: whoever controls the control plane can read them.

Your files, in transit. The files your agent deploys pass through us on the way to your machine. When an agent uploads a bundle out of band, 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. That timestamp says when, not who.

Technical logs. Our servers log each request: method, path, response status, size, duration, and the caller's IP address. This is ordinary operational logging, used for debugging and for investigating abuse.

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. It is counting, not tracking.

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. No ad networks, no third party analytics, no tracking pixels other than our own first party counter described above, no profiles, no fingerprinting.
• 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 three cookies, all of them strictly functional. There are no advertising or analytics cookies, so there is no consent banner to dismiss.

• sp_session: your console sign-in, as a signed token. There is no session table; the cookie carries its own proof. HTTP-only.
• sp_auth_state: set when you request a sign-in link and consumed when you click it. It is what ties the emailed link to the browser that asked for it, which is a security control, not a convenience.
• sp_viewer: set on a share hostname after someone verifies their email to view a restricted project. Scoped to that one share origin.

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 rented for you, and they are reachable at a public URL. Two consequences worth being explicit about:

• 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 host the app; we do not inspect its traffic and we do not log what happens inside it.
• Anything you deploy to a public project is public. Do not deploy other people's personal data, secrets, or anything you would not hand to a stranger with the link.

For restricted projects, viewers verify their email address through our sign-in provider before the gate lets them through. We store that address on the project's access log so the project's owner can see who opened it.

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. Receives your email address and sends the link or code. Also used to verify viewers of restricted projects.
• SendGrid (Twilio): the emails we send ourselves, which today means share invitations. Receives the recipient address and the message.
• Stripe: subscriptions, as described in section 4.
• OpenRelay: the virtual machines your projects run on. Your deployed files and environment variables are pushed onto machines they operate.
• DigitalOcean: hosts the control plane, so our database and logs sit on infrastructure they operate, and its weekly snapshots of that host include our database.
• GitHub: serves the marketing site at getspawnpoint.com, and stores a compressed copy of our database for 30 days each time we deploy a new version of the control plane, as our off-site backup.
• 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 mention it because it is true, not because we like it.

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 runs in the United States, and our database and logs sit there. Your machines run in the region chosen for them, which may be elsewhere. Our 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: a daily copy of the database is kept on the host for 14 days, a copy is stored with GitHub for 30 days on each deploy, and the host is snapshotted weekly. Deleted data leaves those on the same schedule.
• Uploaded deploy bundles: 30 minutes at most, and deleted immediately once used.
• Deploy rate-limit records: 24 hours, 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; API tokens until you revoke them.
• Subscription records: kept as long as tax and accounting law requires, which is longer than your account. Stripe keeps the invoices.
• 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. 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. Restricted projects are gated at a separate origin from the console, so the two cannot reach each other's cookies. 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.

No system is perfectly secure, and we are early software in public beta. If you find a vulnerability, please tell us at founders@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 founders@getspawnpoint.com and we will action it 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 linger in backups for up to 30 days.

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: founders@getspawnpoint.com.