Privacy Policy

Last updated: September 16, 2026

This Privacy Policy describes how Eudaimonic Inc. ("DeepSpace," "we," "our," "us") collects, uses, and shares information in connection with the DeepSpace SDK, the developer platform, the deep.space website, and apps that developers build and deploy on top of them.

DeepSpace serves three groups, and the rules differ depending on which one you are. Developers are people who sign in to the DeepSpace dashboard, scaffold apps with create-deepspace, and deploy them to the platform. End-users are people who sign in to (or visit) one of those deployed apps. Sponsorship applicants are event organizers who submit the form at deep.space/sponsorship without creating an account. Where the treatment differs, we say so explicitly.

Every statement in this policy about what the platform does or stores is grounded in the current version of the published SDK and platform source. When the platform changes, we update this page and the "Last updated" date.

1. Who we are

DeepSpace is operated by Eudaimonic Inc., a Delaware corporation with offices at 23 Wheeler Rd, Setauket, NY 11733, United States. We publish the `deepspace` and `create-deepspace` npm packages, run the platform workers that back deployed apps, and provide the authentication, storage, billing, payments, and integration infrastructure that those apps rely on.

For the purposes of GDPR and similar laws, Eudaimonic Inc. is the controller of the personal information described in this Privacy Policy that we hold about you in your capacity as a DeepSpace developer, as a visitor to deep.space, as a sponsorship applicant, or as an end-user of the DeepSpace authentication and platform services. For content you create inside an app built on the platform, the developer of that app is the controller and we process that content on the developer's behalf (see §2.2 and §4.3). We do not currently have an EU representative appointed under Article 27 of the GDPR; if and when we are required to appoint one, we will publish the representative's contact details on this page.

See §14 for contact details.

2. Information we collect

We collect only what we need to operate the service, bill correctly, review sponsorship requests, prevent abuse, and improve the platform. Information reaches us in three ways: directly from you (for example, when you contact us, submit a sponsorship application, invite a collaborator, or make a purchase), from the sign-in provider you choose to authenticate with (GitHub or Google), and automatically from your use of the service (the request metadata, logs, and cookies described in §6 and §8). The categories below are organized by which group the information is collected from.

2.1 Developers

  • Account information: name, email address, and profile image supplied by GitHub or Google when you authenticate. Developer sign-in (`npx deepspace login` and the developer dashboard) is GitHub or Google only; we do not expose email-and-password sign-in to developers. The OAuth tokens the provider issues during sign-in are stored in our authentication database so the sign-in link can be maintained.
  • Session records: each sign-in session is recorded with its creation and expiry times, the IP address the session was created from, and the browser or CLI user-agent string. A session expires thirty days after its last activity, or when you sign out (see §8), after which its record can no longer be used to sign in.
  • Billing information: handled by Stripe, our payment processor. We do not see or store payment card numbers. We store an opaque Stripe customer identifier and your subscription, credit balance, and invoice history. If you redeem a promotional code or receive a credit gift from us, we store the code, the campaign it belonged to, the email address it was issued to, and who redeemed it, so that a code cannot be redeemed twice.
  • Deploy and release metadata: the immutable identifier of each app you own, the subdomain and custom-domain routes attached to it, the timestamp, Cloudflare version identifier, and acting account for each release, the build artifacts you upload (compiled worker code and bundled static assets, kept so that a release can be rolled back), the Cloudflare resource bindings you have configured, and the integrations enabled in your app's manifest. Deployed workers are tagged inside Cloudflare with your DeepSpace user identifier and the app identifier so that usage can be attributed to you.
  • Application secrets: values you set with `npx deepspace secrets` are stored in a per-app secrets store that we operate on Cloudflare Durable Objects. Each value is encrypted at the application layer with AES-256-GCM under a data key that is unique to your app; the data key is itself wrapped by a platform key that is held only in worker configuration, never in the database. On deploy, the current values are also provisioned as Cloudflare secret bindings on your worker so your code can read them. Secret values can be read back through the CLI by the app's owner, by collaborators the owner has added, and by DeepSpace administrators acting under §11; we do not use them for any purpose other than provisioning your worker and supporting you.
  • Usage telemetry: per-invocation operational counters (request path, HTTP method, country reported by Cloudflare's network, Cloudflare colocation, HTTP status, CPU and wall-clock time) attributed to each app you own, plus the runtime logs your worker emits. We use this to enforce quotas, calculate billing, surface analytics and logs in your dashboard, and investigate operational problems. See §6.
  • OAuth tokens for connected services: if you connect your DeepSpace account to a third-party service through a platform integration, the resulting OAuth access and refresh tokens are stored encrypted at rest. See §11.
  • Stripe Connect details: if you opt into receiving developer payouts, Stripe collects your identity, banking, and tax information directly through Stripe Express. We store only the opaque Stripe account identifier and the status flags Stripe reports to us (for example, whether payouts are enabled).
  • Custom-domain purchase evidence: if you purchase a domain through us, we capture the date, IP address, and user-agent associated with your acceptance of the registrar's terms of service, and we pass that IP address to Stripe with the checkout session for fraud prevention. The registries we use require this as evidence for responding to chargebacks and abuse complaints. Domains bought through us are registered in our own registrar accounts using our registrant contact details with WHOIS privacy enabled; your name, postal address, and email address are not submitted to the registry.
  • App source repositories: when you push your app's source to its DeepSpace-hosted git repository (the remote the CLI configures for your app), we store the repository contents — commits, branches, tags, and file history — together with the push, workspace, and release metadata needed to operate the repository (which account pushed, which refs changed, and when) on our own Cloudflare infrastructure. Commits carry the author name and email address configured in your local git installation, exactly as git records them. Repositories are not hosted on GitHub or any other third party, and they are retained after an app is undeployed until you ask us to delete them (see §12).
  • Collaborators and ownership transfers: when you invite a collaborator by email address, we store that address (before the invitee has an account, if necessary) and send the invitation through our email provider from invites@updates.deep.space; the invitation carries your display name and the app's name. The owner and every accepted collaborator of an app can see each other's email addresses. Ownership transfers are recorded with the identifiers of both accounts.
  • Feedback and support requests: when you run `npx deepspace feedback` or submit a credit request, we store your name and email address as they appear on your account at that moment, the text you send, and — for CLI feedback — the CLI version, Node.js version, operating system, and app identifier you sent it from.
  • Test accounts: if you create synthetic test accounts for automated testing, their credentials are stored server-side so that you can retrieve them on another machine. Test accounts are intended to be synthetic; do not reuse a real password for one.
  • Ad-click identifiers: if you arrive at deep.space from one of our own advertisements, the advertising network's click identifier (such as a gclid, wbraid, or gbraid) is captured in a first-party cookie (see §8), and if you then create an account it is stored alongside your account identifier so we can attribute the signup to our advertising and report it as described in §4.

2.2 End-users of apps built on the platform

When you sign in to an app built on the DeepSpace SDK, you are signing in to DeepSpace. Your account is held in one central directory, so the same DeepSpace account — and the same account identifier — recognizes you on any other app on the platform that you choose to sign in to. DeepSpace is the controller of your account identity. The developer who built the specific app you are using is the controller of the content you create inside that app; we host that content on the developer's behalf as part of operating the platform.

  • Account information: when you authenticate with GitHub or Google, we receive the name, email address, and profile image those providers supply, together with the OAuth tokens the provider issues for the sign-in link. The SDK's default sign-in card also includes an email-and-password form; it signs in accounts that already exist and does not create new ones, and the password is stored only as a salted scrypt hash, never in clear text.
  • Authentication state: a session cookie set on the central DeepSpace authentication origin and, separately, on the origin of each app you sign in to, plus a short-lived signed identity token (fifteen minutes) that the app's client mints from that session and presents to its own worker. Each session is recorded with the IP address and user-agent it was created from. See §8 for the full cookie inventory and lifetimes.
  • Per-app profile: when you sign in to an app, the app's own database records your DeepSpace user identifier, name, email address, profile image, the role the developer has assigned you, and the time you were last seen, so that the app can show you to other members and enforce its permissions.
  • App content: records, messages, files, collaborative-document state, AI conversations, and similar content you save inside an app are stored in databases and storage that DeepSpace operates on the app developer's behalf. The developer's app code is what reads, writes, and decides who within the app can see what. Files an app stores in its shared (app-wide) file area are served from the app's own address without authentication, so anyone who has a file's URL can retrieve it; files stored in your private per-user area require you to be signed in.
  • Anonymous use: where an app allows it, you may also participate without signing in. In that case the app sees only a temporary identifier generated for the duration of your connection, with a fixed "Anonymous" display name and viewer-level permissions, and no DeepSpace account or database row is created or persisted for you.
  • Platform-level metadata: session timestamps, IP address (used to operate the network and detect abuse), user-agent, and the per-invocation request metadata and runtime logs described in §6.
  • AI assistant actions: many apps built on the SDK include an AI assistant that runs under your identity. The assistant can be configured by the developer to read records, and — by default in the SDK scaffold — to create, update, and delete records on your behalf. Those actions are bounded by your own role-based permissions inside the app, but you should treat the assistant as a tool you have asked to act on your data. See §7.
  • Payment information: if you make a purchase inside an app (a subscription, a one-time product, or a tip), payment is processed by Stripe through Stripe Checkout. We do not see or store card numbers. We store the purchase amount, the app it was for, the Stripe identifiers needed to issue refunds, and tax data Stripe returns to us. The developer of the app can see the email address on your DeepSpace account next to your purchases, refunds, and disputes in their earnings reports (see §4.3).
  • Integration data: where a developer's app asks you to connect a third-party account (for example, Google), the OAuth grant happens between you and the third party. We store the resulting access and refresh tokens encrypted at rest, together with the email address of the connected third-party account, and use them only to fulfill requests you or the app make on your behalf. See §5 for Google specifics. Where an app connects tools through Composio, Composio hosts the consent flow and stores the connection tokens itself, keyed by your DeepSpace user identifier and the app identifier; we send Composio no other information about you.
  • Voice and video: where an app enables real-time voice or video, the audio and video stream directly between your browser and the media provider (LiveKit, OpenAI, or ElevenLabs) under a short-lived token we mint. LiveKit tokens carry your DeepSpace user identifier and display name so that other participants can see who you are. We store session identifiers and billed minutes, not recordings or transcripts; an app may choose to persist transcripts as its own content.

2.3 Sponsorship applicants

You do not need a DeepSpace account to request an event sponsorship. When you submit the form at deep.space/sponsorship, we create an application and review record in our platform database.

  • Contact and organization information: your first and last name, email address, and the organization or community you represent.
  • Event information: the event name, type, date, format, estimated attendance, website, what you are requesting from DeepSpace, optional LinkedIn, X, and Instagram links, and any additional comments you choose to send.
  • Submission metadata: the time we received the application and the operational request information described in §6. In particular, Cloudflare Workers Logs may contain the request IP address, headers, user-agent, URL, method, and status for seven days. Rate-limiting counters are used to prevent automated or excessive submissions.
  • Review information: whether the application is new, approved, or declined; the time and DeepSpace administrator responsible for the latest decision; and any internal review note. Authorized DeepSpace personnel can read the application and review record in our administrative console. It is not made available to app developers or other applicants.

3. How we use information

  • Operate, maintain, secure, and improve the SDK and the platform.
  • Authenticate you and keep your account secure.
  • Bill developers for their use of paid platform features, and process payments by end-users for purchases inside apps built on the platform.
  • Detect and prevent abuse, fraud, denial-of-wallet attacks, and security incidents, including rate-limiting sign-in attempts per email address and unauthenticated requests per IP address.
  • Measure traffic to the deep.space website and the performance of our own advertising (see §6 and §8).
  • Respond to support requests and feedback.
  • Assess and administer event sponsorship applications, contact organizers about their request, preserve the decision record during the retention period, and prevent duplicate or abusive submissions.
  • Comply with legal obligations.
  • Send the small number of service emails the platform generates today: collaborator invitations sent on a developer's behalf, and replies to support and privacy requests. Stripe sends payment receipts directly. We do not send account-verification, password-reset, or deploy-notification emails at this time.
  • We do not send marketing email without consent, and we do not use personal information to train AI models.

4. How we share information

We do not sell personal information, and we do not "share" personal information for cross-context behavioral advertising (each as defined under the California Consumer Privacy Act, as amended by the California Privacy Rights Act). We share information only in the circumstances below.

4.1 Sub-processors used by the core platform

We rely on the following providers to operate the platform itself. They process information on our behalf, under their own terms.

We also publish a standalone subprocessor list at deep.space/subprocessors, covering the core platform and every per-integration service, with the data categories that reach each provider and a dated record of additions and removals.

  • Cloudflare, Inc. — Workers for Platforms, Durable Objects, R2, KV, D1, Vectorize, AI Search (which parses, chunks, embeds, and indexes documents that apps upload to a managed knowledge base, using Workers AI models), Browser Rendering (used only to capture screenshots of pages on the platform's own domains at an app's request; the image is returned to the app and not stored by us), Workers Logs, Analytics Engine, rate-limiting counters, and the Cloudflare Registrar. All DeepSpace infrastructure, every deployed app, and the data those apps store run on Cloudflare's network.
  • Stripe, Inc. — payment processing and Stripe Connect for developer payouts.
  • Resend, Inc. — transactional email delivery (collaborator invitations, and email that apps send through the email integration).
  • Anthropic, PBC — Claude model APIs used by SDK-side AI features when an app routes traffic through the Anthropic proxy or integration.
  • OpenAI, L.L.C. — GPT, image, speech, and realtime-voice model APIs used by SDK-side AI features when an app routes traffic through the OpenAI proxy or integrations, and the summarization step of the web-search integration.
  • Cerebras Systems, Inc. — inference API offered through the Cerebras proxy.
  • Google LLC — Gemini model APIs used by SDK-side AI features when an app calls the Gemini integration; Google OAuth for sign-in; the Google Workspace APIs that back the Google integration described in §5. Separately, when a signup is attributable to one of our own Google Ads advertisements, we report that conversion to Google Ads: the advertising click identifier that accompanied the visit, the fact and time of the signup, a one-way SHA-256 hash of the email address, used solely so Google can match the conversion to the ad click (see §8 for the cookie involved), and an internal account identifier used only to prevent the same signup from being counted twice. This measurement reporting is the only advertising-related data flow to Google, and it concerns our own ads only. For this reporting, Google acts as an independent controller for its advertising services rather than as our processor; we treat it as measurement of our own advertising, not as "sharing" for cross-context behavioral advertising.
  • GitHub, Inc. — GitHub OAuth for sign-in, and public repository metadata through the GitHub integration. App source code and git repositories are hosted on DeepSpace's own Cloudflare infrastructure, not on GitHub.
  • ElevenLabs, Inc. — text-to-speech, voice synthesis, and conversational-agent APIs when an app enables voice features.
  • LiveKit, Inc. — audio/video room hosting when an app enables real-time AV features. Media streams flow directly between participants and LiveKit; DeepSpace only mints access tokens.
  • Porkbun LLC — domain registration for top-level domains that Cloudflare Registrar does not handle.

4.2 Per-integration third-party services

When a developer enables a platform integration, calls made through that integration leave the platform and reach the named third-party service. Except where a row says otherwise, calls are made with credentials that we hold, so the provider sees the request as coming from DeepSpace; the app controls what goes into the request, and each integration's provider is the controller of whatever an app sends to it through that integration. The current set of third-party services that may receive data through the platform's integration catalog, grouped by the role they play, is:

  • AI model providers: Anthropic (chat completions, and a grounded web-search endpoint that Anthropic itself runs), OpenAI (chat completions, image generation, text-to-speech, Whisper speech-to-text, and realtime voice sessions, where audio streams directly between the end-user's browser and OpenAI under a short-lived token minted by the platform), Cerebras Systems (chat completions, exposed through a passthrough proxy that forwards the request to Cerebras's API as-is), Google (Gemini chat completions and Gemini image generation), and Cloudflare (AI Search and Workers AI models for the managed knowledge base).
  • Voice and conversational-AI provider: ElevenLabs (text-to-speech, voice listing, and conversational agents).
  • Real-time audio and video: LiveKit (room hosting; media streams flow between participants and LiveKit directly, and DeepSpace mints access tokens only).
  • Agent tool connections: Composio (end-user connections to third-party apps — Gmail, Slack, Notion, and other toolkits — for AI-agent tool use; Composio hosts the OAuth consent flow and stores each end-user's connection tokens, keyed by their DeepSpace user identifier and app identifier, and DeepSpace stores no tokens itself).
  • Web search, scraping, and extraction: SerpAPI (which backs our general web search, Google Scholar search, Amazon product search, and LinkedIn profile lookups, each grouped in our catalog under the kind of result the developer is asking for), Exa, Firecrawl, Apify (web scraping and automation actors), and DataForSEO (SEO, search-results, and large-language-model visibility data). The advanced web-search endpoint additionally sends the search query and the text of the pages it retrieves to OpenAI to produce a summary.
  • Contact and lead enrichment: Prospeo (contact-enrichment lookups) and Anymail Finder (email-address finding).
  • News, weather, sports, and finance: NewsAPI, OpenWeatherMap, API-Sports (football, basketball, baseball, and American football), Finnhub, Alpha Vantage, the public Coinbase market-data API, and the public Polymarket markets API.
  • Transactional email: Resend (we send our own platform email through Resend, and apps can send email through the email integration).
  • Files and media generation: CloudConvert (file conversion), fal.ai (AI image, video, and audio model runs), Freepik (image editing — background removal, upscaling, relighting, style transfer, and expand — and stock asset downloads), and Shotstack (video editing and rendering).
  • Social and messaging platforms: Slack (only when an app makes a call through that integration, using an access token the app itself supplies).
  • Developer and content-platform metadata (read-only catalog access): GitHub (public repository, commit, pull-request, issue, contributor, and tree metadata), YouTube (video search and video metadata), and twitterapi.io (public X (Twitter) profiles, posts, search, follower graphs, lists, communities, and trends).
  • Reference data: Wikipedia, NASA's public APIs, the New York City MTA public feeds and New York State Open Data, and the public Jolpica / Ergast Formula 1 API.
  • Self-hosted services we operate: a LaTeX rendering service we run on Cloudflare for compiling LaTeX source to PDF.

4.3 App developers

When you sign in to an app built on the SDK, the app receives your DeepSpace user identifier, name, email, and profile image so it can recognize you. The developer of that app is responsible for handling that information, and any content you create in the app, under their own privacy policy and terms. Our Terms of Service require developers to disclose to their end-users anything material about how their app processes data that this policy does not cover, including which third-party integrations the app calls and how its AI assistant is configured.

Developers, and the collaborators they add, can read everything their app stores, including records, files, messages, and AI conversations, through the app's administrative role and through direct platform tooling. If you purchase something inside an app, the developer can see the email address on your DeepSpace account next to that purchase, refund, or dispute in their earnings reports.

For app content, we act as the developer's processor (or "service provider" under the CCPA): we process it only to provide the platform, on the developer's instructions, and as described in this policy. Developers who require a written data processing agreement may contact us at the address in §14.

4.4 Legal and safety

We may disclose information if we believe disclosure is required by law, court order, or governmental request, or if disclosure is necessary to investigate suspected fraud or abuse, enforce our Terms, or protect the rights, property, or safety of users or the public.

4.5 Business transfers

If Eudaimonic Inc. is involved in a merger, acquisition, financing, or sale of assets, user information may transfer as part of that transaction. We will notify affected users where required by law, and any successor will be bound by this policy with respect to information collected under it until they notify you otherwise.

5. Google user data

This section describes how DeepSpace handles user data obtained through Google APIs. It applies in addition to the rest of this Privacy Policy, and controls where there is any conflict with respect to Google user data.

DeepSpace's use and transfer to any other application of information received from Google APIs adheres to the Google API Services User Data Policy, available at https://developers.google.com/terms/api-services-user-data-policy, including the Limited Use requirements.

5.1 Scopes we request and the purpose of each

When a user connects a Google account through a DeepSpace platform integration, we request only the OAuth scopes needed for the feature the user is enabling at that moment, and we request further scopes incrementally if the user later uses a feature that needs them. The scopes we may request are:

  • openid, https://www.googleapis.com/auth/userinfo.profile, and https://www.googleapis.com/auth/userinfo.email — used to authenticate the user, retrieve the user's display name, profile image, and email address from Google, and associate the user's Google identity with their DeepSpace account.
  • https://www.googleapis.com/auth/gmail.readonly — read-only access to the user's Gmail messages, threads, labels, and message metadata. DeepSpace uses this scope solely to display the user's email correspondence inside the connected DeepSpace app — for example, alongside the contact, deal, and account records the user has chosen to maintain there — so that the user can review their own correspondence in one place. Nothing is sent, altered, or deleted under this scope.
  • https://www.googleapis.com/auth/gmail.send — requested only when the user asks the connected app to send an email from their Gmail account. Used solely to send the message the user composed or approved, including replies threaded onto an existing conversation.
  • https://www.googleapis.com/auth/gmail.modify — requested only when the user asks the connected app to change the state of a message: mark it read or unread, add or remove labels, archive it, or move it to Trash. Because Google defines this scope to include sending, a user who has granted it can also send through the app. DeepSpace never permanently deletes messages; we do not request the full mail scope that permanent deletion requires.
  • https://www.googleapis.com/auth/calendar.events — reading, creating, and deleting events on calendars the user owns, only when the user or the app the user is using initiates the action.
  • https://www.googleapis.com/auth/drive.file — limited Drive access scoped to files the user has explicitly created with, or opened with, the connected DeepSpace app.
  • https://www.googleapis.com/auth/contacts.readonly — read-only access to the user's Google Contacts so the connected DeepSpace app can show contact information alongside the user's other app data.

5.2 Limited Use of Google user data

In accordance with the Google API Services User Data Policy Limited Use requirements:

  • DeepSpace uses Google user data only to provide or improve user-facing features of the DeepSpace app the user has connected their Google account to. We do not use Google user data for any unrelated purpose.
  • DeepSpace does not transfer Google user data to others except (i) as necessary to provide or improve those user-facing features, (ii) to comply with applicable law, or (iii) as part of a merger, acquisition, or sale of assets with notice to users.
  • DeepSpace does not use Google user data to serve advertisements, including retargeting, personalized advertising, or interest-based advertising.
  • DeepSpace does not sell, rent, lease, or trade Google user data.
  • Scope note: the commitments in this section concern Google user data obtained through the Google Workspace APIs described in §5.1. The email address on your DeepSpace account (however you signed up, including via Google sign-in) is part of our own account records; its only advertising-related use is the one-way-hashed conversion-measurement report described in §4 and §8, which involves no ad serving, retargeting, personalization, or interest-based advertising.
  • DeepSpace does not use Google user data, including data accessed through the Gmail API, to develop, improve, train, fine-tune, or evaluate any generalized or non-personalized artificial-intelligence or machine-learning model. No DeepSpace platform feature transmits Google user data to Anthropic, OpenAI, Cerebras, Google Gemini, ElevenLabs, or any other third-party model provider listed in §4.1, and the SDK's default AI assistant has no tool that reads Google user data. Developers who access Google user data through the platform must themselves comply with the Google API Services User Data Policy, including its Limited Use requirements, and must not send Google user data to any AI provider or other third party except as that policy permits for the user-facing feature the user has enabled.
  • DeepSpace personnel do not read or otherwise access Google user data, including data accessed through the Gmail API, except (a) with the user's explicit consent, for example to investigate and resolve a support issue the user has reported, (b) where strictly necessary for security purposes such as investigating abuse, fraud, or a suspected violation of these terms, (c) to comply with applicable law, or (d) for internal operations where the data has been aggregated and de-identified such that it cannot be linked to any individual user.

5.3 Storage, encryption, and processing location

  • Gmail message content — headers, bodies, attachments, and labels — is retrieved on demand from the Gmail API at the moment a user views it within a connected DeepSpace app, transmitted to the user's authenticated browser session, and is not persisted in DeepSpace's databases or backups. An app developer can choose to copy content into the app's own data collections; in that case the developer's own retention and deletion rules apply.
  • OAuth access and refresh tokens issued by Google are stored in our billing-and-integrations database together with the granted scopes, the token expiry time, and the email address of the connected Google account. Tokens are encrypted at the application layer using AES-256-GCM with a per-record random initialization vector. The encryption key is derived via HKDF-SHA256 from a secret managed outside of the database and held only in the worker runtime, in addition to the encryption-at-rest provided by the underlying storage platform. Tokens that were stored before application-layer encryption was introduced are re-encrypted the next time they are refreshed.
  • All processing of Google user data takes place on Cloudflare Workers infrastructure operated by DeepSpace, within the same Cloudflare account that runs the DeepSpace platform. Google user data is not passed to any sub-processor listed in §4.1 other than Cloudflare, and is never passed to a sub-processor that is not listed in §4.1.
  • DeepSpace enforces application-layer access controls, request rate limiting on the Google endpoints, operational request logging (see §6), and security response headers on the worker that handles Google user data. The application completed a Cloud Application Security Assessment (CASA) Tier 2, the assessment level Google requires of applications that request Gmail restricted scopes, and the authorized assessor delivered its Letter of Verification to Google in June 2026. We repeat the assessment as Google's verification program requires.

5.4 Revoking access and deleting Google user data

A user may disconnect a connected Google account from a DeepSpace app at any time from the integrations area of that app's settings. When a user disconnects:

  • DeepSpace immediately calls the Google OAuth token revocation endpoint to revoke the OAuth grant on the Google side.
  • The encrypted access and refresh tokens, and the connected-account email address stored with them, are deleted from DeepSpace's database.
  • No further Gmail data is fetched on the user's behalf after revocation. If a user revokes access from their Google account settings instead, the stored tokens stop working immediately and are deleted the next time the app attempts to use them.
  • Because DeepSpace does not persist message content server-side (see §5.3), there is no server-side message store to delete in addition to revoking the token.

5.5 Contact regarding Google user data

Questions, complaints, or requests that relate specifically to data obtained through Google APIs, including Gmail data, may be sent to privacy@deep.space or contact@eudaimonic.one. We will respond in accordance with the Google API Services User Data Policy and applicable law.

6. Telemetry, logs, and site analytics

  • Per-invocation usage records: we record operational metadata for every request made to a deployed app. This includes the app identifier, the request path (with the query string removed), the HTTP method, the outcome of the invocation (for example, ok, exception, or canceled), the HTTP response status, the country reported by Cloudflare's network, the Cloudflare colocation that served the request, and the CPU and wall-clock time the request consumed. Records are indexed by the app developer's user identifier so each developer can see usage and be billed for their own apps; they are not indexed by individual end-user identifier. We use this data to enforce quotas, calculate billing, surface analytics to the developer of each app, and investigate operational problems.
  • The per-invocation usage record does not contain the body of the request, the values of HTTP headers, the URL query string, the client IP address, or the contents of any database read or write.
  • Runtime logs: every deployed app worker, and each of our platform workers, writes structured runtime logs to Cloudflare Workers Logs for every request, with no sampling. The raw log rows that Cloudflare stores include the request URL, method, and status, the client IP address, the request headers (including cookies), the user-agent, and whatever the app's own code logs. These logs are retained by Cloudflare for seven days. When a developer views logs through the dashboard or `npx deepspace logs`, they see only their own app's rows and only a filtered set of fields. Error logs may include error text returned by an upstream provider, which can echo fragments of the failing request.
  • Binding-usage records: apps that use compute-style Cloudflare bindings can emit a separate per-call usage event so the developer can be billed for that consumption. The SDK ships dedicated meters for Workers AI calls and Vectorize queries, plus a generic meter that an app's own code can call for any other compute-style binding. These usage events record the binding type, the operation performed, and a numeric usage figure (for example, tokens or bytes) — not the content of the call.
  • AI usage records: each call through an AI proxy or integration writes a billing row containing the billed account, the calling user, the app identifier, the provider, the total token count or other billing unit, and the cost. The prompt, the response, and the model name are not stored in that row.
  • Per-invocation, binding-usage, and site-analytics records are stored in Cloudflare Analytics Engine and retained according to that service's default retention window, which Cloudflare documents as approximately three months at the time of writing.
  • Website analytics: for visits to deep.space itself, our routing layer records one server-side, cookieless analytics event per page navigation containing the page path (without the query string), any utm_source, utm_medium, utm_campaign, utm_content, and utm_term tags on the link that brought you, the host name of the referring site, and the country reported by Cloudflare's network. It does not record your IP address, your user-agent (which is read only to exclude bots), or any identifier for you, and no client-side analytics script is loaded on deep.space, the dashboard, or scaffolded apps. Apps deployed on the platform are not measured this way.
  • Operational logs are kept for the period needed to investigate incidents and to satisfy our security and audit obligations. We do not use these logs for advertising.

7. AI features

Apps built on the SDK can route traffic through proxies and integrations we operate to large-language-model and other AI providers, including Anthropic, OpenAI, Cerebras, Google (Gemini), ElevenLabs, fal.ai, Freepik, and Cloudflare (AI Search and Workers AI for managed knowledge bases). All of these calls are made with API keys that we hold; developers do not supply their own keys, and we do not attach your DeepSpace identity to the request sent to the provider. Each request passes through our infrastructure in memory so that we can count tokens for billing, and is then forwarded to the chosen provider together with whatever content the requesting app includes in the request body. Whatever a developer's app sends — including content authored by you, the end-user, that the app chooses to include as context — is transmitted to the chosen provider.

We do not currently set provider-specific opt-out headers on outbound AI traffic. Each provider treats prompts and outputs according to its standard API default, which for most providers in this list excludes use of the content for training new models but may allow short-term retention for safety, abuse monitoring, or service quality. You should treat any content you send through an AI feature as visible to, and processable by, the chosen provider on that provider's standard API terms.

We do not store the contents of AI proxy traffic. What we keep is the billing record described in §6.

Managed knowledge bases: an app can upload documents to a knowledge base that we provision for it on Cloudflare AI Search, which parses, chunks, embeds, and indexes those documents so the app can search them. Each app gets its own isolated instance, which is deleted when the app is undeployed. Documents you provide to such a feature are content of the app and are governed by the app developer's policy.

The SDK's scaffolded AI chat feature does, by default, save each turn of an AI conversation — your messages, the assistant's replies, and any tool calls the assistant makes — into the app's own database, so the conversation is durable across page reloads. That persisted chat history is content of the app you are using and is governed by that app developer's privacy policy and terms. By default, users assigned the app's administrator role can read every user's chat history in that app. The scaffold's default assistant uses Anthropic Claude models.

The scaffolded AI feature also gives the assistant the ability to act on records on your behalf — by default, the assistant can inspect the app's schema, query and read records, create, update, and delete records, and look up your own profile, bounded by the role-based access controls the developer has configured for your role inside the app. It has no default tool for web browsing, file access, sending email, or calling integrations. App developers can narrow or extend this default. You should treat the assistant as a tool you have asked to act on your data, and review what it does.

8. Cookies and local storage

  • Authentication is held in two related artifacts. (a) An HttpOnly, Secure, SameSite=Lax session cookie, scoped to a single origin, set on the central DeepSpace authentication origin when you sign in, on the DeepSpace dashboard, and on each deployed app you sign in to (apps scaffolded from the SDK template set their own copy of the session on their own origin after the one-time sign-in exchange). Sessions last thirty days and are extended while you remain active; a session that sees no activity for thirty days expires. No authentication cookie is shared across subdomains, and a session cookie on one origin is not visible to code running on a deployed app at a different origin. (b) A short-lived signed identity token (fifteen minutes) that an app's client mints from the session and presents to the app's own worker and to platform services; it carries your user identifier, name, email address, and profile image, and is renewed from the session as needed.
  • Short-lived CSRF cookies used by the OAuth sign-in and CLI sign-in flows, scoped to the corresponding callback path, marked HttpOnly, Secure, and SameSite=Lax, with lifetimes that match the flow (five minutes for the social-login flow and ten minutes for the CLI flow).
  • Interface preferences (theme, sidebar state, drafts) stored in your browser's localStorage on each app.
  • If you arrive at deep.space from one of our own advertisements (for example, a Google Ads click), the landing page stores the advertising network's click identifier (a gclid, wbraid, or gbraid) in a first-party cookie on the deep.space domain for up to 90 days. We use it for one purpose: attributing signups to our own advertising, including reporting that a signup occurred back to the advertising platform the click came from. It is set and read only by us and is not used to track you across other sites. It is set only when the address of the page you land on carries such a click identifier — normally the case only when you arrive through an advertisement — and never during ordinary browsing. We honor the Global Privacy Control (GPC) signal: if your browser sends it, this cookie is not set at all, and any click identifier captured earlier is cleared on your next visit.
  • We do not use third-party advertising cookies, cross-site tracking, or client-side analytics scripts.

9. Data location and international transfers

We are based in the United States, and our infrastructure runs on Cloudflare's global edge network and on the Cloudflare account we operate. Data may be processed in the United States and in any region Cloudflare operates from, and our sub-processors listed in §4 operate primarily from the United States. If you use the service from outside the United States, your information will be transferred to, stored, and processed there. We rely on the contractual protections offered by our providers, including standard contractual clauses where applicable, for international transfers.

10. Your rights and choices

Depending on where you live, you may have rights including access, correction, deletion, portability, the right to object to or restrict certain processing, and the right to withdraw consent where processing is based on consent. We honor these rights for everyone, regardless of where they live, to the extent we are able.

  • Choice: most of the information described in §2 is necessary to provide the service, and we cannot operate an account or review a sponsorship application without it. Everything else is engaged only by a choice you or the app you use makes — submitting optional sponsorship details, connecting a third-party account, using an AI feature, making a purchase, or arriving from one of our advertisements — and you can decline by omitting optional form fields, not using that feature, disconnecting the account (see §5.4), or sending the Global Privacy Control signal (see §8). Where we rely on your consent, you may withdraw it at any time without affecting the lawfulness of processing before the withdrawal.
  • Accuracy: we rely on the information on your account to reach you about security, billing, and privacy matters, so you are responsible for keeping it accurate and current. Your name, email address, and profile image come from the sign-in provider you used; changing them there and signing in again updates them with us, and you can update other profile information through the settings area of the dashboard or of an app you are signed into. If you believe information we hold about you is inaccurate or incomplete, tell us at privacy@deep.space and we will correct it.
  • Account deletion is handled by request, not self-service. Email privacy@deep.space (or contact@eudaimonic.one) from the address on your account. When we delete an account we remove your identity record from our authentication database (your name, email address, profile image, sessions, the link to the sign-in provider you used, and any advertising click identifier stored at signup), your billing profile and credit balance, and — for developers — we undeploy your apps and delete their repositories, release history, secrets, files, and app databases. Content you created inside apps built by other developers is governed by those apps' own policies, and you may need to contact the developer of each app to delete it there. Records we are required to keep for tax, accounting, fraud-prevention, audit, or security-incident reasons — for example, invoice ledgers, refund and dispute records, and operational logs — may persist for the periods set out in §12 even after your identity record is removed.
  • Sponsorship applicants can ask us to access, correct, or delete an application before its automatic deletion date by emailing privacy@deep.space from the address supplied on the form. A sponsorship application is separate from any DeepSpace account held by the same person, so deleting one does not automatically delete the other.
  • You can request a copy of the personal information we hold about you by emailing the same addresses. We provide it in a commonly used, machine-readable format.
  • We verify requests before acting on them, typically by confirming that the request comes from the email address on the account or sponsorship application. An authorized agent may make a request on your behalf if they provide evidence of your written authorization. We will not retaliate or discriminate against you for exercising any of these rights.
  • Our legal bases (where the GDPR or UK GDPR applies): performance of our contract with you (operating the platform, authentication, billing); our legitimate interests in securing and improving the service, preventing abuse, and measuring our own website traffic and advertising, balanced against your interests; compliance with legal obligations; and your consent where we ask for it. You can object to processing based on legitimate interests, and you have the right to lodge a complaint with your local supervisory authority.
  • California residents: we do not sell personal information or share it for cross-context behavioral advertising, and we honor the Global Privacy Control signal as a valid opt-out request. You have the rights to know, delete, and correct your personal information and to non-discrimination, exercisable through the contacts above. We do not use or disclose sensitive personal information for purposes other than those permitted by the CCPA.

11. Security and operator access

  • All traffic to and from the platform is encrypted in transit using TLS. Data is encrypted at rest using the encryption that the underlying Cloudflare storage services provide. OAuth tokens for third-party integrations and application secrets are additionally encrypted at the application layer using industry-standard authenticated encryption (currently AES-256-GCM), with keys derived from or wrapped by secrets managed outside the database. We may update the specific cipher or key-derivation function over time as cryptographic best practice evolves; the Google-specific guarantees described in §5.3 take precedence over this paragraph where the two overlap.
  • DeepSpace personnel have administrative access to the platform infrastructure that is technically capable of reading data we host on Cloudflare, including app content, application secrets, and runtime logs, and, for support and abuse investigations, of acting within an app as a specific user under a short-lived token that is marked as such. Access is limited to a small operations team and is used only for the purposes described in this policy: investigating support requests, investigating suspected abuse or security incidents, responding to legal obligations, and operating the service.
  • Sponsorship applications and their internal review records are visible to authorized DeepSpace personnel in the sponsorship area of our administrative console so they can assess the request, contact the organizer, and record a decision.
  • This operator access is distinct from any "admin" role a developer may assign inside their own app. A developer's assignment of an in-app admin role to a particular end-user controls what that end-user can do within that one app and is separate from any DeepSpace personnel access to platform infrastructure.
  • Changes to our Cloudflare account configuration are monitored automatically and reviewed by our team; those internal records identify the DeepSpace staff member who made each change, not users.
  • Organizational measures: we maintain written information-security and privacy practices covering access control, change management, incident response, backup and recovery, and vendor review, and we review them at least annually. Access to production systems and personal data is role-based, limited to the people who need it for their work, protected by multi-factor authentication, and reviewed periodically; it is removed when a person's role ends. Personnel with such access are bound by confidentiality obligations and receive security and privacy training. We assess a sub-processor before engaging it and record every addition and removal on our subprocessor list.
  • Files an app stores in its shared file area are retrievable by anyone who knows the URL (see §2.2). Developers are responsible for not placing personal or confidential information in that area, and end-users should assume that anything an app publishes as a shared file is not private.
  • We are working toward a SOC 2 Type II examination but have not yet received a SOC 2 or ISO 27001 report, and we do not currently claim compliance with those standards. Consider this before sending us regulated personal data.

Privacy requests

To access, export, or delete the personal data we hold about you, or to report a concern about how your data has been handled, contact privacy@deep.space. We verify requests before acting on them, and complete verified deletion requests within 30 days, except where we are required to retain information by law or by a written agreement with you.

Security concerns

If you have a security or vulnerability concern, reach out to security@deep.space. We appreciate responsible disclosure.

Breach notification

If we become aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of personal data we hold, we will notify affected developers and, where required by law, affected end-users and regulators without undue delay after confirming the breach.

12. Data retention

  • Active account data — your identity record and the apps and content tied to it — is kept for as long as your account is active.
  • Session records, including the IP address and user-agent captured at sign-in, are kept while the session is valid — thirty days from the last activity, or until you sign out — after which they can no longer be used to sign in and are deleted on request with the account.
  • Per-invocation telemetry, binding-usage records, and website analytics are retained for approximately three months in Cloudflare Analytics Engine and then rotated out by that service.
  • Runtime logs captured by Cloudflare Workers Logs are retained for seven days.
  • Short-lived authentication artifacts — CLI sign-in sessions (10 minutes), social-login codes (5 minutes), identity tokens (15 minutes), and per-flow CSRF cookies — are cleared automatically by the timers built into the flow.
  • Billing records (invoices, refunds, disputes, and the related Stripe identifiers) are retained for at least seven years to satisfy applicable tax, accounting, and consumer-protection obligations, even after an account is closed.
  • Encrypted OAuth tokens for third-party integrations are deleted when you disconnect the integration. If you delete your account without disconnecting first, the tokens are deleted as part of removing the identity record.
  • Undeploying an app removes it from the network but does not delete its data: the app record, its git repository and release history, its secrets, its files, and its databases are retained so the app can be redeployed, until the developer asks us to delete them or deletes their account. Rollback bundles are evicted oldest-first when an app reaches its storage cap; deleted git workspaces are purged after seven days. When an app gives up a subdomain, the name is reserved for the previous owner for 30 days, and the registry records which account released it for that period.
  • Advertising click identifiers captured at signup are kept with your account until the account is deleted; the conversion report to Google is sent once, within 90 days of the click.
  • Sponsorship applications and their review records are retained for 730 days from submission and are then deleted automatically during the next daily retention sweep. You may ask us to delete an application sooner as described in §10.
  • When you ask us to delete content, we remove it from active systems within 30 days and from routine backups within 90 days. Records covered by a legal hold, a security investigation, or the retention obligations above are not removed until those holds expire.

13. Children

DeepSpace is not directed to, or intended for use by, children under the age of 13 (or, in the European Economic Area, the United Kingdom, and certain other jurisdictions, under the age of 16). We do not knowingly collect personal information from children. If you believe a child has provided us with personal information, contact us at privacy@deep.space and we will delete the information. Developers who build apps directed at children are responsible for complying with the Children's Online Privacy Protection Act and similar laws.

14. Contact and changes

Privacy questions, requests, and notices may be sent by email to privacy@deep.space or contact@eudaimonic.one, or by mail to Eudaimonic Inc., Attn: Privacy, 23 Wheeler Rd, Setauket, NY 11733, United States.

We may update this policy from time to time. Material changes will be communicated through the platform or by email. The "Last updated" date at the top of this page reflects the most recent revision, and continuing to use the service after a change takes effect means the updated policy applies to you.

Monitoring and enforcement: we review this policy, and our practices against it, at least annually and whenever the platform changes in a way that affects how personal information is handled. Complaints and inquiries about our handling of your information sent to privacy@deep.space are logged, investigated, and answered, and we cooperate with data-protection authorities in resolving them. Personnel who handle personal information in breach of this policy are subject to disciplinary action, up to and including termination. If you are not satisfied with our response, you may complain to the supervisory authority for your jurisdiction (see §10).

By using the DeepSpace SDK, the platform, or any app built on the platform, or by submitting a sponsorship application, you acknowledge that you have read this Privacy Policy.

DeepSpace

The first app engine — secure, scalable, and production-ready from day one.

If the page stays like this, your browser may be out of date — the links above still work.