In force
Privacy policy
What we keep, where it goes, how long, and what you can do about it. Each section opens with a short summary; press “Full text” for the detail.
The short version
- We keep what you give us so ForgeOS can do the work: your account, your requests, your files and your projects.
- We do not sell your data. We do not use it for ads. We use no ad or analytics trackers.
- Your work is sent to AI model providers to be done. The free ones have not said what they keep.
- Our cookies keep you signed in and note which ForgeOS site sent you. None track you across other sites.
- You can export or delete your data at any time.
- You must be 16 or older.
- If a breach exposes your personal data, we will tell you.
- Questions or requests: privacy@medina19.com.
This summary helps you read the policy. The full text below is the policy.
1. Who this covers
This covers the ForgeOS site, the product, sites you publish with it, and support.
Full text
ForgeOS is operated by Medina19, whose operating entity is still being formed; this page will name it and its registered address as soon as it exists, under section 10. This policy covers the ForgeOS product site, the ForgeOS product itself, sites and share links you publish through it, and the support we provide with it. It covers people who create a workspace, people invited into one, and anyone who opens a page a customer has published.
ForgeOS runs on one host, operated by us. Everything described as “held” below is held on that host unless a row says otherwise.
2. What we hold, and why
We keep your account details, what you ask ForgeOS to do, your files and projects, and basic logs. We never store your password, only a scrambled check of it. We take no payment details. We use no ad trackers.
Full text
Grouped by what it is for. Each row names the thing held as the software stores it.
Your companion and conversation memory
The companion keeps the name, time zone, preferences and optional location you give it, reminders you ask it to set, and personal facts you ask it to remember or confirm when it offers. Those saved personal facts belong to your sign-in, rather than to everyone in a shared workspace. Optional learning and pattern settings control the extra personalisation they describe. You can turn them off in the companion settings.
Conversations are stored with the workspace where they happened. To make a long conversation usable, we also keep a searchable index and summaries of its earlier turns. Relevant past turns, summaries and saved facts can be included in a request to the model answering you. They therefore follow the provider disclosures in section 3, including the unknown retention of some free gateways. Do not put information in a chat that you cannot share on those terms.
Browser notifications are optional. If you enable them, we store the device subscription needed to deliver reminders through your browser’s push service. You can unsubscribe in the companion settings or revoke notification permission in your browser. We keep reminders and saved personal facts until you remove them or delete your account; backup copies expire under the retention described in section 5.
Your account
| What | Why |
|---|---|
| Your email address, lower-cased, and the workspace name you typed | The address is how you sign in and where reset links, invites and verification links go. The workspace name becomes the workspace's identifier. |
| A scrypt digest of your password, with a random 16-byte salt | To check a sign-in. The password itself is never stored, and the digest cannot be turned back into it. |
| If you sign in with Google or GitHub: the provider's stable account id, the email address the provider says it has verified, and your display name | Membership is bound to the provider's id rather than the address, because addresses change hands. An address the provider has not verified creates nothing. |
| Whether your address has been verified, and when | So we know a reset link would reach you. Nothing is withheld from an unverified account. |
| Membership rows: workspace, member, role (owner, admin, member, viewer), and when they were added | To decide what each person may do. Deny is the default; an unknown role can do nothing. |
| Sessions: a random 32-byte token, of which only a SHA-256 digest is stored, with workspace, member, and creation and expiry times | To keep you signed in for up to 30 days. A copy of the session database lets nobody in. |
| Password-reset, verification and invite links: only a SHA-256 digest of the link, with who it was for and when it expires | Single-use and expiring: a reset link lasts 30 minutes, a verification link 7 days, an invite 7 days. A stolen database cannot reconstruct a working link. |
| Sign-in throttle rows: a SHA-256 digest of the account key and of the connecting IP address, a failure count, a window start and a lock-until time | Five free failures in fifteen minutes, then a lock from one minute doubling to fifteen. Keys are hashed so the throttle does not accumulate a readable list of who signs in from where. |
Your workspace
| What | Why |
|---|---|
| Goals you write, and the append-only record of every state change and approval (the coordination store and audit chain) | They are the instruction and the evidence. Nothing here edits or deletes a past event, so what happened can be proved. |
| The conversation about each goal: author, text (up to 4,000 characters a message) and time, append-only | Shown back to you as the record of what was asked and answered. |
| Repository checkouts: a git clone of each repository you connect, and the full contents of each project ForgeOS creates for you | ForgeOS cannot plan or change software it cannot read. Checkouts live under the workspace's own directory on this host. |
| Reference files you upload, up to 8 MB a file (128 MB for audio or video) and 512 MB a workspace, plus up to 40,000 characters of text extracted from each for a build | So a build can read the brief, screenshot or document you attached. You can remove any of them at any time. |
| Provider connections: the keys you connect, encrypted and bound to your workspace and that connection | To ask that provider for work on your account. A key never appears in an export, a log line, an error message or a backup. |
| Where you connected GitHub under Connections and granted repository access: the GitHub token, held the same encrypted way (signing in with GitHub alone grants no repository access and stores no such token) | So a repository you already authorised can be cloned without a second sign-in. |
| The spending ledger: the ceilings you set, open reservations and settled charges, per workspace and per provider | So a request that would cross your limit is refused before it is made. A workspace with no limit set can spend nothing. |
| Review settings: person or model review, and whether the workspace has acknowledged the free models' undeclared retention (see section 3), with who recorded it and when | Turning either on is always an act somebody performed, on the record. |
| A bounded log of what kind of action each action was (observe, recommend, draft, execute, communicate, modify production, delete, commit): the last 200 records | So authority questions can be reviewed by label. Older records are dropped as new ones arrive. |
| Share links and publications: an opaque token or address, which project and ref it points at, when it was made and when it expires or was revoked | To serve the page you chose to share, and to take it down when you say so. |
The instance as a whole
| What | Why |
|---|---|
| How each model performed — pooled across this instance, carrying no repository name and no workspace identifier | So a model that keeps failing is tried later, and one that works is tried sooner, for everybody. See section 4. |
| A daily count of calls your workspace made to the shared free models | So usage can be shown, and so each workspace’s daily share of the free models (300 calls a day, shown on the pricing page) can be enforced. A number and a date; nothing about the work. |
| A cached list of the models your connected providers offer | So new models are usable without waiting for us to write them down. Public catalogue data from your provider, not data about you. |
| A record of which free gateways answered or refused recently | So a build asks a working gateway first. A gateway name and a moment. |
| A mail outbox: recipient, subject, a digest of the body, when it was sent and whether it was delivered | To answer “did the reset link go?” The body itself is not kept. |
| Product signals: that a workspace shared a result, or how it answered a question the product asked about itself, and when | To learn whether the product is worth using. A note that contains an email address is dropped rather than filed. |
Referrals: when you arrive through a link that carries a published site’s name (?ref=), that name, the time and the page you landed on; if you then sign up, which site referred the new workspace | To see which published sites bring people to ForgeOS. A site name, a time and a page; nothing about you. The name rides in a cookie for 30 days (section 11). |
| Serving counts, in memory only: requests, errors, rejections and latency per route and per workspace | To see whether the host is coping. No request content is kept, and the counts vanish when the service restarts. |
| Service logs, written to the host's system journal | To keep the service working and to answer you when it does not. They record what the service did and any errors, and rotate under the host's journal settings. |
| The web server's access log: for every request to this site, including a page a customer published, the connecting IP address, the time, the request line, the status, the bytes sent, the referrer, the browser's user-agent string and how long the request took | The ordinary record a web server keeps so an operator can see what the host is doing and diagnose a fault. It is the one place a visitor to a published page appears, and it is written to a file on the host, not to the journal. |
| If you connect the ForgeOS browser extension: the browsers you connected (a name such as “Chrome on Mac” and a digest of each one’s token), the tasks you gave them, and for each step the action taken and the address of the page it was on | So a task can go step by step and you can see what was done. The text of the pages is read to choose each step and is not kept. What is typed into password, card, bank and one-time-code fields is never read or sent, and the extension never types into them. |
| Support requests you open under Support: the category, subject, description, any build or feedback id you link, the replies on the thread, its status, and a workspace-scoped digest of who opened or replied to it (not your address). Kept in the instance’s customer-operations store, not in the workspace’s own directory | So a request and its answers stay in one thread that members of the workspace can see. Deleting the workspace erases them; the store’s tamper-evident audit log keeps a one-way hash of each saved version, which reveals nothing to anyone who does not already hold the original. |
| Erasure receipts: which workspace was deleted, by whom, when, and how many files and bytes were removed | So a deletion can be evidenced. Identifiers and counts only, never content. |
What we do not collect
No analytics or advertising trackers
Every page on this site loads its scripts and styles from this host only, and the browser is told to refuse a script or stylesheet from anywhere else. There is no third-party analytics, pixel or advertising code, and no request this site makes goes to anybody who could count you.
No payment details
There is no payment collection, so no card, bank or billing details are held. See pricing.
No readable secrets
Passwords, session tokens, reset links and throttle keys are stored only as digests. Provider keys are encrypted. Secrets in your code are referenced in evidence, never copied into it.
No mail bodies
The outbox keeps a digest of what was sent, not the text.
Not your customers' data
ForgeOS has no access to your customers' data unless you grant it as its own separate authority. That authority is off by default, nothing in the software turns it on by itself, and its state is shown in Trust & control inside your workspace (sign in to view Trust & control).
3. Where it goes
Your content goes to AI model providers so they can do the work, and to the few services listed below. We do not sell your data or use it for ads.
Full text
Your content leaves this host only through the mechanisms below, and each is something you or the operator set up. Nothing is sold, and nothing is shared for advertising.
The model provider you connect
When a goal needs a model and you have connected one, the goal, the code the work needs and the change under review go to that provider on your own key, under your agreement with them, and never past the spending limit you set. Which providers may run work is a setting you control; no provider you would pay runs work until you connect one.
The free gateway pool, when you accept its condition
Projects ForgeOS creates for you are built, and since 2 September 2026 independently reviewed, by open-weight models reached through free gateways we hold the keys to: whichever of OpenRouter, Groq, Cerebras, Together, DeepInfra, Hugging Face, Mistral and NVIDIA this instance is configured with. This is the house free fleet. Those gateways have not declared what they retain, and we say so rather than assume otherwise. Before source code goes to them, a member of your workspace records an acknowledgement that the retention is unknown; until somebody records it, no diff is sent and a model review refuses and says which declaration is missing. Review sends the change and the objective — not your repository history, credentials or conversation — and only the models we named may review. The acknowledgement is revocable.
The free gateway pool, when you give the browser extension a task
Each step sends your task, and the address, title, visible text and list of buttons, links and fields of the tab the extension is working in, to the same house free fleet, to choose the next step. What they retain is undeclared, as in the entry above. Nothing is sent until you start a task, and only from the tab it runs in; what is typed into password, card, bank and one-time-code fields is left out. Disconnecting the browser on /os/browser stops it at once.
Google or GitHub, when you sign in with them
Your browser is sent to the provider and back. From Google we ask for your id, email and basic profile; from GitHub we ask for your user record and verified email. We receive your provider id, verified address, display name and an identity token for that sign-in. Repository access is separate and starts only when you connect GitHub under Connections.
GitHub, through the app this instance registered
The operator registers one GitHub App for the whole instance. The app carries metadata and verified-email read access, plus contents, pull-request and checks write permissions for the governed delivery/reporting path. ForgeOS still writes only its own
forgeos/branches, never merges or writes your default branch, and never receives deployments, secrets, workflow, administration or issue permissions. Its own credentials are held in the same encrypted custody as yours.Our mail server, when the instance sends mail
Password-reset links, address-verification links and invitations go out through the SMTP server the operator configured, to the address you gave. An instance with no mail server configured says so rather than pretending to send.
Anyone holding a link you shared or an address you published
A share link (
/shared/<token>/) shows one built project to anyone who has the link for 30 days, renewable, until you revoke it. A published site (/s/<address>/) is public on purpose until you unpublish it. Both serve committed files from your checkout and nothing else, and pages are served in a sandbox so they cannot read this site's cookies.The host we run on
One DigitalOcean droplet, and, where an off-site copy is configured, backup archives in an object-storage bucket the operator controls (DigitalOcean Spaces). Backups refuse secret-shaped material rather than carry it.
Nobody else
We do not sell your content, share it for advertising, hand it to another customer, or ourselves train models on it. We cannot make that promise for the free gateways: they have not declared whether they retain or train on what they are sent (see above), and nothing goes to them until a member of your workspace acknowledges that.
Lawful demands
If we are legally compelled to disclose something, we intend to tell you unless we are prohibited from doing so.
How these companies are treated
The model gateways, our host and our mail server process your data only to provide ForgeOS. Each works under its own terms and privacy policy. We have not signed a data processing agreement with the free gateways, which is why their retention is shown as unknown. A provider you connect works under your own agreement with it.
If ForgeOS changes hands
If ForgeOS moves to a company formed to run Medina19, or to a buyer, your data moves with it under this policy. We will tell you first.
4. Separation between customers
Each workspace is kept apart from every other. The only thing shared across workspaces is an anonymous record of how well each AI model did.
Full text
Each workspace has its own SQLite databases and its own directory on the host. Every read and write resolves through that workspace's path, with symlink-aware containment, so a request from one workspace cannot name another's files. Provider keys are encrypted with the workspace and connection as authenticated data, so a ciphertext lifted into another workspace's slot fails to decrypt rather than opening.
One thing is deliberately shared, and it is not yours. When a model is asked to make a change, ForgeOS records how that attempt went — which model, on which class of work, whether the change applied, whether your repository’s own tests passed, and whether it needed repairing. Those records are pooled across every workspace on this instance, so the tenth person to try a model that failed nine times for other people does not have to find that out again.
What crosses is the model’s record. What never crosses is you: the repository name is replaced before the record is written, your workspace identifier is never written at all, and no part of your code, your goal or your conversation is included. A pooled record cannot be attributed back to a workspace, and your own workspace’s experience always outranks the pooled one when ForgeOS chooses a model for you.
Stated as intent and evidence, not as a completed audit. There is an adversarial test suite, dated 23 August 2026, covering one workspace reaching another’s goals, conversations, exports, sessions, repositories and files, provider connections, spending limits and stored keys — including with a valid session of its own and the exact identifier of the thing it is asking for. That is evidence, not certification: no third party has audited it, and it is a suite we wrote about our own software. The tests live in the repository and the trust page reports what they cover.
5. How long we keep it
We keep your content while your workspace exists. Backups and logs expire after a few weeks.
Full text
The real numbers, as the software applies them.
| What | How long |
|---|---|
| Goals, audit chain, conversation, checkouts, reference files, provider connections, spending ledger, review settings | For as long as the workspace exists. Removed when the owner deletes the workspace (section 6). |
| Browsers connected through the extension, their tasks and each step’s record | For as long as the workspace exists. Removed when the owner deletes the workspace. Disconnecting a browser stops it and its tasks and keeps their record. |
| Sessions | 30 days from sign-in, or until you sign out, change or reset your password, or the workspace is deleted. Expired rows are swept at each sign-in. |
| Password-reset links | 30 minutes, single use. Issuing a new one retires the old one; spent and expired rows are swept when the next is issued. |
| Address-verification links and invitations | 7 days, single use; swept the same way. |
| Sign-in throttle rows | Removed once their fifteen-minute window and any lock have both passed, at the next recorded failure. |
| Share links | 30 days, renewed by sharing again. Revoked and expired rows are removed when the next share is made. |
| Published sites | Until you unpublish, or publish the same project at a different address. |
| Mail outbox | 90 days. Older rows are removed when the next message is recorded. |
| Action-kind log | The last 200 records per workspace. |
| Serving counts | In memory only; gone when the service restarts. |
| Pooled model records, gateway health notes, cached model catalogues | Kept while useful. None of them names you. |
| Support requests and their replies | For as long as the workspace exists. Erased when the workspace is deleted; the audit log keeps only a one-way hash of each saved version. |
| Erasure receipts and the closed workspace's registry row | Kept, so the deletion can be evidenced. Identifiers and counts only. |
| Local backups of the host | Seven days by default, then pruned. Deleted content persists in a backup until that backup rotates out. |
| Off-site backups, where configured | 30 days by default, and the operator sets the number. On-host archives are kept 7 days by default and mirrored repository bundles 14; the operator sets those too, so the instance you are using may keep them longer than the default. Ask, and you will be told what this one is set to. |
| Service logs | 14 days, and at most 500 MB, whichever comes first. |
| The web server's access log | Rotated by the host's own log rotation, which on this distribution keeps 14 days. |
6. Your controls
You can export your data, delete your workspace, unpublish sites and remove files yourself, at any time.
Full text
Each of these is a button or a request that exists in the product today.
In the companion settings you can inspect, edit or delete saved personal facts, export your companion data, and use “Forget everything” to clear that personal memory and, if you can manage the workspace, the things the workspace was asked to remember. Clearing companion memory does not erase the original workspace conversations. Use the conversation or workspace deletion controls for those, and account deletion to leave the service. Contact support@medina19.com if you need help exercising the rights described below.
Export
One machine-readable document of what this workspace holds. It has every goal with its history and conversation, and whether the audit chain verifies. It has your provider connections (never the key values), spending ceilings, charges and model-outcome records. It has your account, the workspace’s members, and your uploaded files listed by name, size and date. It has your share links, publications, browser-extension records, feedback, support requests and the shared features’ record. A manifest lists every section, and a section that could not be read is marked, not dropped. It leaves out your code, which you download from the project menu. It leaves out secrets and sign-in secrets such as your password’s hash and session tokens; it says whether each exists, never what it is. It also leaves out the bytes of uploaded files and a support operator’s internal notes. Ask for any of those (section 10).
Delete the workspace
Owner only, with your password re-entered (or the workspace name typed, if you sign in through a provider). The workspace is closed, every session is revoked, and its checkouts, projects, goals and files are removed from the host — then checked, so you are told “deleted” only when it is. The sign-in credentials, memberships and second factors this workspace held are erased too; if this was your only workspace, your outstanding reset links and your address-verification record go as well. What stays: the registry row marked closed and the receipt, and — if your address belongs to other workspaces — your sign-in records for those. The workspace’s support requests and their replies are erased too (see section 2). Ask us to remove what remains (section 10).
Revoke a share
Every share link for a project, dead at once.
Unpublish
Takes the public address down. Because a published page is cached in front of the application for fifteen seconds, a viewer who loaded it in that window may see it for up to fifteen seconds more. Publishing history can also be rolled back to an earlier commit.
Change your password
Needs the current one. Every other session for you is ended at the same time.
Sign out everywhere
Signing out ends this session. Resetting your password ends every session you have, on every device — the answer to “I think somebody else is in my account.”
Withdraw the free models' condition
The undeclared-retention acknowledgement can be revoked. After that, no diff is sent to an undeclared provider.
Remove files, members, connections and limits
Reference files can be forgotten, members removed (a workspace always keeps one owner), providers disconnected, and the spending limit changed or left unset — unset means nothing is spent.
7. Your rights
Wherever you live, you can ask to see, correct, export or delete your data. Email privacy@medina19.com. We answer within 30 days.
Full text
Depending on where you are, you may have rights to access, correct, export, delete or restrict the processing of your personal data, and to object to it. The controls in section 6 are how we intend to honour access, export and deletion without your having to ask.
Not yet mapped to a specific regime. This policy does not name a lawful basis under the UK GDPR, EU GDPR, CCPA or any other regime, does not identify a data controller entity or representative, and does not list international transfer mechanisms — the operating entity is still being formed, and inventing those here would be the most misleading thing on this page. Whatever your regime, write to privacy@medina19.com and we will honour the request directly: access, correction, export, deletion and restriction all work today by asking, and section 6 is how most of them work without asking.
8. Security
Passwords and links are stored only in scrambled form. Keys are encrypted. If a breach exposes your personal data, we will tell you.
Full text
What the software actually implements. No more is claimed than this.
Passwords
scrypt (N=215, r=8, p=3) with a random 16-byte salt, compared in constant time. At least 8 characters. A password stored at an earlier, lower cost (N=214, r=8, p=1) still signs you in, and its digest is rebuilt at the current cost the next time it does; the parameters are stored beside each digest, so raising them again never locks anybody out.
Sessions and links
32 random bytes; only the SHA-256 digest is stored. Reset, verification and invite links are single-use and expire. OAuth sign-ins carry a single-use anti-forgery state and a PKCE verifier, and a redirect must finish within ten minutes.
The sign-in cookie
The session cookie,
forgeos_session: HttpOnly, Secure, SameSite=Lax, Path=/, 30 days. Script cannot read it and a cross-site form cannot send it, which is what makes state-changing requests safe. Secure is dropped only when an operator explicitly runs a non-TLS instance.Throttling
Sign-in, sign-up and password checks share one throttle keyed by hashed account and hashed address. Sign-in failures answer the same way whether or not the account exists.
Per-workspace isolation
Own databases, own directory, path containment on every read, and keys encrypted to the workspace. Described in section 4, with the limit that no third party has checked it.
Provider keys
Encrypt-then-MAC over HMAC-SHA256 from the standard library, bound to workspace and connection; read only through an already-admitted file descriptor; every refusal counted; the plaintext never reaches a log, an export or an error message.
Published pages
Served from committed files only, under a sandboxing policy that gives each page an opaque origin, with declared media types and a size cap. Addresses that imitate well-known brands or a sign-in flow are refused at publish time.
Authority
Reading a repository does not imply writing to it, writing does not imply deploying, and none of it implies customer data or spending. ForgeOS pushes only its own
forgeos/branches, only to a repository where you installed its GitHub app and allowed writing, and never merges or writes your default branch. The controls the software enforces are on the trust page.
To report a vulnerability, write to security@medina19.com and give us a chance to fix it before publishing.
9. Children
You must be 16 or older to use ForgeOS.
ForgeOS is a tool for people who own or maintain software. It is not directed at children, and we do not knowingly create a workspace for anyone under 16. If you believe a child has created one, tell us and we will delete it. If we learn that an account belongs to someone under 16, we close it and delete its data.
10. Changes, and contact
We will tell you before a big change. Questions: privacy@medina19.com.
Full text
We will tell customers before a material change takes effect rather than after — on this page and, where we can, to the address on your account. The date at the top is the date the current text took effect, and no change is ever retroactive. A test in the repository ties sentences on this page to the code they describe, so the page fails a build when the software drifts from it.
Questions and requests about your data: privacy@medina19.com, or ask through support and a person will answer.
12. Rights where you live
Everyone gets the same rights, wherever they live. Email privacy@medina19.com from your account address. We answer within 30 days. It is free.
Full text
Everyone
- See the personal data we hold about you, and get a copy.
- Correct it.
- Delete it.
- Take it with you in a machine-readable form.
- Object to, or ask us to limit, how we use it.
- Withdraw any agreement you gave, such as the free models’ condition.
We may ask you to confirm the request from your account address so we know it is you. We will not treat you worse for using these rights.
Europe and the UK
You can also complain to your local data protection authority. Section 7 explains what this policy does not yet name under the GDPR.
California and other US states
You have the right to know what we collect, to delete and correct it, and to opt out of its sale or sharing. We do not sell or share personal information, as those laws define it, and we do not use it for targeted advertising. An authorised agent may make a request for you.
13. If there is a breach
If a security breach exposes your personal data, we will email the affected account owners without undue delay. We will say what happened, what data was involved, and what you can do. We will also tell regulators where the law requires it, within 72 hours where that is the deadline.
Something wrong here?
If you are a customer's security team, a lawyer, or someone who has spotted something wrong, tell us. A policy that survives scrutiny unchanged was not read carefully enough.