Velai is a job search tool, and keeping your résumé private is part of what it is. This page explains what we collect, why, and how you can control it. If anything here is unclear, use the contact page — we read every message ourselves.
Your résumé
Velai reads your résumé file in your browser, on your own device. The file itself is never uploaded to us: what Velai works with is the text and the structured résumé read from it.
If you aren't signed in, that structured résumé is kept in this browser's local storage and nowhere else. If you are signed in, it is saved to your account so it follows you across devices, and it is encrypted with AES-256 before it is stored, under a key kept on our web server rather than in the database. The same goes for the copies Velai keeps for you: earlier versions saved in the résumé editor, the résumé a role kept when you marked it applied, and tailored résumés filed on a role.
Besides you, only an AI assistant or the Velai browser extension that you connect yourself can load your résumé. Velai never sends it to an employer: you apply on the employer's own site. No AI model on our servers reads it. When AI helps read or tailor it, your name and contact details are taken out first and the request goes, encrypted, to a sealed server that we can't read (see AI processing).
To find jobs that fit, Velai sends role titles taken from your résumé, plus a country and seniority filter, to our search index. Those searches are not logged. Strong, Good and Stretch are worked out in your browser. The one exception is daily picks, if you turn them on: then our server ranks your saved résumé against the week's roles once a day, by the same rules and with no AI, to choose what it emails you (see Email).
Our analytics never record your résumé. Session replays mask every word on the page and anything you type, clicks are recorded without the text you clicked, and page addresses lose the role titles that ranking by fit puts in them (see Cookies & analytics).
You can delete your résumé from account settings at any time. That also removes its earlier versions and the copies kept on roles you marked applied. Deleting your account removes everything, tailored résumés included.
What we collect
When you create an account, we collect the email address and profile information you provide. You can sign in with Google, a passkey, an email code, or a username and password. Google, passkey, and email-code sign-in run through WorkOS, our sign-in provider, which holds your account record under its own data-processing terms — we never see or store your Google password. Username-and-password sign-in is also processed by WorkOS.
Once you're using Velai, we store the things you create: your tracked applications, saved résumés, saved searches, and prep answers. This data lives in a PostgreSQL database we run on our own servers. Each record is encrypted with AES-256 under a key only we hold before it is stored, so the database holds those records only in encrypted form, and so do the backups taken since the move; older backups expire on their normal schedule. A few values we have to look records up by, such as a sign-in username or an email, are kept as keyed hashes that can be matched but not read back. Your data is only ever accessed by our servers — never exposed directly to the browser or to other users. Until October 2026 this data was held in Google Cloud Firestore; it has been moved here, and the copy in Firestore was deleted in October 2026.
We keep an anonymous record of the searches people run: the words typed, the place and filters, how many jobs came back, and which result was opened. It holds no account id, IP address or browser id, so a search can't be traced back to you, and it is how we learn what people look for and which jobs and employers we're missing. It is encrypted the same way as account data and deleted after 90 days. Searches Velai builds from your résumé (ranking by fit, For you, and Today) are not recorded. If you're signed in, the jobs you click, open, save, or apply to are tied to your account so we can improve your results. Search records made before the move were not copied, and were deleted with the rest of Firestore.
For reference, the kinds of account data these storage claims cover include:
- Your profile, account record, saved searches, and companies you follow
- Applications you track (with a copy of the résumé on file when you mark one applied), daily apply counters, and jobs you have opened before
- Résumé editor history, tailored résumés, and per-job analyses used for tailoring
- Cached interview-prep responses, interview questions and answers we store for your applications, and questions you mark as favorites
- Career stories, citation sources, and product feedback you submit
- Search queries, result clicks and opens, and company-follow funnel steps we log
- Connected AI client registrations, pairing codes, credentials, and usage budgets
- Weekly digest send state, email suppressions, and welcome-email send records
- Connect-page and other waitlists plus contact-form messages (often without an account)
- App configuration, daily market aggregates, signed-in viewer sessions, and historical credit-grant records
If you join a waitlist (for example, “tell me when it's ready” on the connect page), we store the email address you enter and which product you asked about — nothing else — and use it only to send you that one notification. You don't need an account for this, and you can ask us to remove it at any time via the contact page.
If you sign up for weekly search alerts while browsing jobs without an account, we store the email address you enter and the search you asked to watch, and use them only to send you new matching roles each week until you unsubscribe.
When you search, we read your IP address on our servers for two things: to default your job search to your country so first results are nearby, and to rate-limit abusive traffic. That country lookup uses a local database on our own server — not a third-party geolocation API — and we do not attach your IP to your account, your saved searches, or your tracked applications for that purpose. That same country check does one more thing: if it places you in the EU or UK, we don't give your browser a long-lived id that would link your search activity across visits — you get one that resets when you close the tab, and we don't currently ask you to opt into anything more. Like nearly every website, our servers keep ordinary technical logs that can briefly include request IPs.
Job search itself runs against a Meilisearch index we operate. When you run a search, our servers send the text you typed and the filter choices you selected to that index so it can return matching listings. If you use rank-by-fit, For you, or similar résumé-backed retrieval, our servers also send a search query derived from your parsed résumé — for example experience role titles, headline profession, inferred adjacent role titles, top skill names, and an experience-level filter from your years of experience — plus a country filter inferred from your résumé location when we can. We do not send your full résumé file or raw résumé text to Meilisearch, and these résumé-built searches are not logged. Location typeahead and facet pickers can send the place text you type to Meilisearch facet search so suggestions match the corpus.
Résumé fit labels (Strong / Good / Stretch) are computed from your résumé and each job's public fields on our servers or in your browser after listings are returned — not by sending your résumé to Meilisearch or Subspace for scoring.
The listings you browse are public information sourced from employers' career pages. Our servers call Subspace's Jobs API (thesubspace.io) to refresh and fill job descriptions — we send job identifiers only, not your résumé or search queries. If you report a listing while signed in and reporting is enabled, we send Subspace's flags API the job URL, job title, the report category you chose (mapped to Subspace's schema), any notes you add, and your Velai user id as reporter_key.
We don't buy marketing profiles about you from data brokers.
How we use it
We use your account data to run the product: to show your tracked applications and keep your résumés and prep answers where you left them. We use your search-activity profile for two things: to make your own results more relevant the more you use Velai, and, looked at in aggregate across everyone, to understand which kinds of job postings people actually apply to so we can improve search for everyone. Velai is free to use today; if we introduce a paid plan it will be listed on the pricing page before anything is charged. We don't sell any of this to advertisers. Derived signals about postings and companies (whether a listing is still live, how long roles stay open, applicant activity reduced to aggregate statistics) may be licensed to third parties through a Data API; those signals never include your résumé, your applications, your saved jobs, your account details, or anything that identifies you.
AI processing
We read your résumé in your browser first. If that quick read misses something we match on, the résumé's text, with your name, email, phone number and links taken out, goes to an AI model on Tinfoil's sealed server. When you customize your résumé for a job, only the lines that match that job and the job's matching requirements go there, to be rewritten. Your browser first checks the server's hardware proof of the code it runs, then encrypts the request so that only that server can read it: our servers pass it on without being able to read it, and Tinfoil's staff can't read it either. We do not keep the original file.
If you have an account, we store the structured résumé with that account until you delete the résumé or the account. Deleting the account deletes that copy from our database; backups that still hold it, in encrypted form, expire on their normal schedule. Deleting the account also asks PostHog to delete the analytics events and replays tied to your account.
Strong, Good, and Stretch are calculated from your résumé and each job's public details. On the website that calculation runs in your browser. A connected assistant can also ask our servers to calculate it from the résumé saved on the account. Finding jobs sends role and skill phrases to our search index, not your full résumé.
Interview-prep search parsing can send the search text you typed to OpenRouter. Audio transcription can send a recording to Groq. Those requests are not your résumé, and no AI model on our servers reads your résumé.
Connected AI clients
If you pair an AI client with Velai from the connect page (Claude, ChatGPT, Gemini, or another app that speaks MCP), that client can — after you sign in and approve the connection — read your saved résumé, your tracked applications, and your job preferences, and save changes back when you tell it to. Anything your AI client reads travels to that provider and is handled under their privacy terms, not ours — we can't control what the provider you chose retains or how it uses what it processes. This only ever happens for a client you connected yourself, and you can disconnect it at any time from account settings, which cuts off all further access.
Browser extension
The Velai extension for Chrome reads a job page in two ways. On the job sites it names when you install it (job boards and applicant-tracking sites such as LinkedIn, Indeed, Greenhouse, Lever and Workday), and on any other site you turn its card on for, it reads each page you open there as it loads, to show a small card with your fit and what's known about the job. Pages that aren't jobs get no card. Anywhere else, it reads a page only when you click its button, or when you pick “Search Velai for” on text you selected. It reads the page's address, title and the job details the page publishes, plus its visible text if you ask it to read the page as the job, or when the page publishes no job details but reads as a job (a heading, an Apply button and a job description). It doesn't keep a list of pages you visit. Chrome asks you before the card is turned on anywhere else: for one site, or once for every site. On a site you turned it on for, the card checks each page inside your browser and tells Velai nothing about pages that aren't jobs.
If you're signed in to Velai in that browser, the extension loads the résumé and job preferences saved on your account, then works out your fit and tailors your résumé inside the extension. It holds the résumé in memory only, never in Chrome's storage, and loads it again after a minute. The tailored copy stays in your browser until you download or copy it. To check the job, the extension sends the role's title and employer to Velai's search. A search you start with the extension's button or a text selection is logged like any search on the website; the card's own check when a job page loads is not logged. The extension keeps the job it is showing and, for two hours, the job page you last opened in each tab (so an application form on a later page knows which job it's for), which Chrome clears when you close the browser, and the sites you turned its card off on.
On an application form, when you pick “Fill from your résumé”, the extension types the name, email, phone, location and links from your Velai résumé into the form's empty fields that ask for them, and attaches your résumé tailored to the job as a PDF. That happens in your browser and sends Velai nothing. The site gets those details only when you send the form yourself; the extension never sends it. After it fills a form, it watches that tab for the site's confirmation that your application was sent, and then adds the job to your tracker as “I applied” does.
When you pick “I applied”, the extension adds the job (its title, employer and the page's address) to the tracker on your Velai account, the same as “Mark as applied” on velai.app. Signing in and editing your résumé happen on velai.app itself, in a small window the extension opens.
We send email through Resend, a transactional email provider, which processes your address and message content on our behalf under its own processor terms. Beyond your address itself, we store which kind of email you've been sent (a waitlist confirmation, the weekly digest, a product update) and its delivery status (sent, bounced, or marked as spam) — not the content of what we send you.
Daily picks are off until you turn them on. When they're on, our server reads the résumé saved on your account once a day, ranks the roles posted that week by the same rules as Today (no AI), and emails you up to five. So no role is sent twice, we keep which roles we've sent you and when, encrypted with the rest of your account and erased with it.
If you have an account, we may also email you now and then about changes to Velai, such as a new feature or a fix to something that wasn't working.
Every email that isn't a direct response to something you just did — the weekly digest, daily picks, a waitlist confirmation, a product update — includes an unsubscribe link that works without signing in and takes effect immediately. If an email to your address bounces, or you mark one as spam, we stop sending to that address automatically. You can also turn the weekly digest and daily picks on or off directly from account settings.
Behavioural analytics ledger
Alongside PostHog (below), we keep a separate behavioural ledger in a PostgreSQL database we run. Your browser batches product events to our telemetry API — the same catalogue of actions we use to understand search and apply funnels. Each row can include: event_id, occurred_at, received_at, session_id, visitor_id, user_id, event_name, source, query_id, job_id, company_domain, position, props. The props field holds event-specific metadata (for example query length or filter counts — not the full text of what you typed). When you're signed in, our server stamps your user id on each row; guests send only session and visitor ids generated in the browser. We use this ledger to improve search quality and to compute aggregate statistics. Rows are deleted after 90 days.
Cookies & analytics
We use a session cookie to keep you signed in. It's httpOnly (invisible to page scripts) and identifies your session — nothing more. The jobs board sets one more tiny cookie the first time you visit: a returning-visitor flag (literally the value 1, with no identifier in it), so the front door can skip the first-visit intro next time.
We use PostHog for product analytics — page views, clicks, and searches — so we can see what's working and fix what isn't. Velai shares one PostHog project with thesubspace.io; we tell events apart with a product tag in the analytics payload, not a separate project. PostHog's US cloud (us.posthog.com, configured as our analytics UI host) processes the data as our processor under their own DPA terms. Browser requests are sent through our own /ph proxy path rather than directly to third-party analytics domains.
PostHog runs cookieless on Velai: no analytics cookie is set. What PostHog needs to hold on to lives in your browser's per-tab storage, so a reload doesn't restart your session, nothing is shared with your other tabs, and all of it is discarded when you close the tab. PostHog events are not linked to your Velai account id unless you're signed in and we identify your session to PostHog — signed-out visits still send page and interaction events. At the PostHog project level, IP addresses are stored ( IP anonymization is off), including for signed-out visitors. We don't run ad trackers or any third-party tracking pixels, and beyond the two cookies above Velai sets none. The Cloudflare Turnstile check on our contact and sign-up forms runs in its own frame and may use its own storage under Cloudflare's terms to tell humans from bots.
PostHog session replay is enabled. Replays capture the layout of the pages you saw, how you moved through them, console logs, and performance data from the session. Every word on the page, labels and tooltips included, is masked before it leaves your browser, and links lose their search terms: we can see where you clicked and scrolled, not what the page said, so a replay of your résumé shows no résumé. Input masking is on too: anything you type is masked — we can see that you filled in a field, not what you put in it. Replays never keep what a page sent to or got back from our servers. Replays are kept for 30 days in PostHog, then expire under PostHog's own retention rules. A replay covers a single tab and is tied to your identity only if you're signed in.
Clicks are recorded by which button or link you pressed, never the text in it or in its labels. Every analytics event carries the address of the page it happened on, with the words you searched removed before it leaves your browser.
PostHog also powers heatmaps, in-app feedback surveys, and short forms when a search returns no results. Surveys may optionally ask for your email address; we use it only to notify you when matching jobs arrive or to follow up on feedback. The field is optional, and every survey works without it. On phone-sized viewports we disable automatic survey UI so it does not overlap page content.
Where data is processed
You may be in one country while our providers and infrastructure operate elsewhere. We have not verified or published a single home region for every data store behind Velai. PostHog product analytics are processed in the United States — our app is configured to use PostHog's US cloud (us.posthog.com). Other processing — including the databases we operate, which hold your account data, search indexes, email delivery, and sign-in through WorkOS — may run outside your country, including in the United States, without us naming a region we have not confirmed in configuration.
Retention & deletion
We keep your account data for as long as your account is active. Search-activity records — which searches, which clicks, which applies — are kept for 90 days and then deleted; after that we keep only aggregate statistics that no longer identify you. The behavioural analytics ledger described above follows the same 90-day deletion window. PostHog session replays are retained for 30 days in PostHog.
You can delete your account yourself from account settings — self-serve, not a support ticket. The flow is: Account tab → Delete account in the danger zone → type DELETE → confirm permanent deletion. When you confirm, this device's browser clears local storage first, then our servers run the deletion; only if that succeeds do we sign you out and clear your session cookie.
That server action removes your profile and every user-owned collection in our migration manifest (for example applications, résumés, saved searches, prep answers, agent credentials, and email digest state keyed to your account). When your sign-in email is a real address, not a synthetic username-only address, it also removes contact-form messages and connect, founding-seat, and credit-pack waitlist entries stored under that address. It deletes the behavioural-ledger rows in PostgreSQL stamped with your account id, asks PostHog to delete the person tied to your account id along with that person's analytics events and session recordings, deletes any sign-in record left in Google's Firebase Authentication from before we moved sign-in to WorkOS, then deletes your WorkOS sign-in record. For a real address it then runs our identity-forget path: global email suppression for that address and deletion from our PostgreSQL identity store.
PostHog data from visits where you were never signed in carries no account id, so it is not linked to you and is not removed. If PostHog can't be reached when you delete your account, the rest of the deletion still completes, and we do not retry the PostHog request. Session replay recordings in PostHog are kept for 30 days, as described above, then expire under PostHog's rules. We have not confirmed a fixed retention period for ordinary analytics events or heatmap data in PostHog. Deletion does not remove contact-form messages or waitlist entries sent from a different email address than the one you sign in with. Anonymous search logs and aggregate statistics are unaffected. Suppression entries for your address stay in place so we do not resume email after you leave.
We do not offer a separate bulk export or machine-readable download of your stored account data. If you need account-held data removed, use self-serve deletion above or email us for help removing waitlist or contact-form records sent from another address.
Your choices
You can edit or delete content you created in the product. To remove your entire account, use the self-serve flow in account settings (Account tab → Delete account in the danger zone → type DELETE → confirm permanent deletion). For questions about privacy or deletion, email hello@thesubspace.io or use the contact page.
Contact
Questions: email hello@thesubspace.io or use the contact page.