Privacy policy
What we hold, and what we do with it
This page is about facts rather than principles: which fields go into the database, which text leaves our servers, which machines it sits on, when it disappears, and what is really deleted when you delete something.
1What this document covers#
| Address | Notes | |
|---|---|---|
| Marketing site | octoryn.studio | The site you are reading. Hosted on Cloudflare Pages |
| Workbench | studio.octoryn.app | Where the work happens, after sign-in. Hosted on AWS in Sydney |
| Mobile apps | iOS / Android | Same accounts, same backend |
| Share pages | /s/ links on the workbench domain | The only entry point that does not require signing in |
“We” means the Octoryn Studio product and whoever operates it; “you” means the person holding the account. When you work as a team, projects, masters and usage belong to the team, not to the individual account — if you are removed from a team, the projects you made there stay with the team.
The operator is OCTOPUS CORE PTY LTD, Australian Company Number (ACN) 696 931 236, Australian Business Number (ABN) 28 696 931 236, a proprietary company limited by shares registered in New South Wales under the Corporations Act 2001, registered on 8 April 2026.
The registered office is not published on this page. Like the numbers above it, it is on the public register held by the Australian Securities and Investments Commission (ASIC) and can be looked up from either the ACN or the ABN.
2What we collect#
The tables below are exhaustive. This is not an “including but not limited to” list — it is every table in the database that has anything to do with you.
Your account
| Data | Where it comes from | Why we need it |
|---|---|---|
| Email address | You, at sign-up | Signing in, password recovery, billing receipts, team invitations |
| Display name | You; if left blank, the part of your email before the @ | Addressing you in the interface and in team member lists |
| Password hash | Derived from your password | Verifying sign-in. We do not store your password itself — see section 4 |
| Sign-up, last sign-in and email verification timestamps | Recorded by the system | Account state and security troubleshooting |
| Session records | Created each time you sign in | Keeping you signed in, and letting you end a session on demand |
| API keys | Created by you | Programmatic access. Only a hash and the first eight characters are kept — see section 4 |
| Push token | When you enable notifications on mobile | Telling you a film is finished. Removing the device removes the token |
| Team membership and role | When you create a team or accept an invitation | Deciding what you can see and change |
What you make
| Data | In detail |
|---|---|
| Project | Title, the premise exactly as you wrote it, format, aspect ratio, language, genre — plus the logline, synopsis, beat structure and style notes the line generates |
| Music you upload | The audio file itself, plus its original filename, duration and content type |
| Episode | Title, summary, and the full script — scenes, headings, action, and every line of dialogue with its speaker |
| Shot | Shot description, camera note, dialogue, speaker, duration |
| Assets | Names and written descriptions of characters, locations and props |
| Masters | Title, duration, sharing state, the share link token, and a view count (a plain counter) |
| Media files | Shot clips, voice-over audio, reference stills, posters, subtitles, the finished MP4, and any music you uploaded |
| Stage records | Each stage's input parameters, result summary, logs and failure reason |
Usage and billing
| Data | In detail |
|---|---|
| Usage records | Which vendor, which model, how many seconds or characters, how long it took, whether it succeeded, and which vendor it fell back from. No text you wrote |
| Credit ledger | Every increase and decrease, the reason, and the balance afterwards |
| Subscription state | Stripe customer and subscription ids, subscription status, current period end |
| Stripe event de-duplication table | Only Stripe's event id and event type — no billing content of any kind |
Feedback you volunteer
When you rate a shot or a master up or down, we record the rating, an optional reason, and whatever free text you type. That record does not identify who wrote it — it is attached to the team and the project, not to your account.
3What we do not collect#
This section matters as much as the previous one. None of the following exists anywhere in the backend — no column, no call:
- IP addresses. Not recorded, not stored, no access logs kept.
- User-agent strings, device fingerprints, screen dimensions or anything else of that sort.
- Third-party analytics of any kind. No Google Analytics, no Plausible, no PostHog, no Sentry, no SDKs. Not on the marketing site, not in the workbench, not in the mobile apps.
- Tracking cookies. The marketing site sets no cookies at all; the workbench sets exactly one, for signing in. See the cookie page.
- Your text, in usage records. A record says “video, xAI, 7.5 seconds, succeeded, 42 s latency”. It does not say what those 7.5 seconds were meant to show.
- Anything about who watched a shared film. The view count is an integer being incremented. There is no per-visitor record behind it.
There are no server-side access logs either
CloudFront, load balancer and S3 access logging are all switched off, as are CloudTrail and VPC flow logs. That is a privacy fact and also a limitation: we do not have a complete access trail to reconstruct after an incident. Application logs are covered in section 7.
None of this is a promise never to change; it describes how the system is built today. If analytics are ever added, this page changes first — see section 14.
4How passwords, tokens and keys are stored#
This section is more specific than most privacy policies, deliberately. “We take your security seriously” carries no information. Parameters do.
| What | How it is stored | How long it lasts |
|---|---|---|
| Password | Never stored in plaintext or in any recoverable form. Derived with scrypt (N=16384, r=8, p=1, 32-byte key, a fresh 16-byte random salt per account). scrypt is memory-hard, which makes bulk cracking orders of magnitude more expensive than it would be against MD5- or SHA-family hashing | Until you change it |
| Sign-in session | You get a 256-bit random string; the database holds only its SHA-256. Sessions are server-side records rather than self-contained tokens, which is why revoking one takes effect immediately | 30 days, extended each time it is used. Changing your password deletes every session you have |
| API key | Shown to you once, at creation. Afterwards we keep only the SHA-256 and the first eight characters, so you can tell your keys apart in a list. Lose it and it has to be reissued — we cannot recover it either | Until you revoke it |
| Email verification link | Hash only, as above | 24 hours |
| Password reset link | Hash only, as above | 1 hour |
| Team invitation link | Hash only, as above | 7 days. Re-inviting the same address invalidates the earlier one |
Session records contain no IP address and no user-agent. The cost of that is honest: we cannot show you a list of recent devices and locations, because we never recorded one.
Invitations store the invitee's email address
Inviting a colleague writes their address into the invitation table, even if they never sign up. That row remains after the invitation expires or is superseded. If that matters to the person you are inviting, ask them first.
5Where your writing goes#
This is the section to read carefully. We do not train models and we do not run inference ourselves — footage, speech and the screenwriting text all come from external vendors. Which means what you write leaves our servers.
Only vendors with credentials configured receive anything
This is structural rather than a policy statement. Every vendor in the capability catalogue carries a “do we have credentials for this” check, and vendors without them are filtered out before routing even begins. Even if that filter were bypassed, the vendor's client refuses to construct without a key. An unconfigured vendor cannot physically receive anything.
Once configured, who gets what
| Vendor | Used for | What it receives |
|---|---|---|
| Octoryn's own AI routing service (api.octoryn.dev) | Screenwriting: outline, episodes, script, assets, storyboard | Your premise exactly as you wrote it, the project title, language, aspect ratio, genre, target runtime and narrative structure, plus whatever earlier stages produced — the outline, the episode summary, the full script. It does not receive your email address, account id or team id. The routing service then forwards the request to a text model of its choosing |
| xAI (Grok Imagine) | Footage and reference stills | The description of a single shot; reference stills inlined in the request as base64 (up to three) |
| Alibaba Cloud (Tongyi Wanxiang, Qwen-TTS) | Footage, lip-sync, speech | Shot descriptions or lines of dialogue. Reference images and audio are passed as publicly reachable URLs which the vendor fetches |
| Google (Veo 3.1, Gemini API) | Footage | Shot descriptions; first frame, last frame and reference images inlined as base64 |
| ByteDance · Volcano Engine (Seedance, Seedream, Doubao Voice) | Footage, speech | Shot descriptions or lines of dialogue; reference images passed as URLs |
| MiniMax (Hailuo, Speech) | Footage, speech | Shot descriptions or lines of dialogue; first-frame references passed as URLs |
| OpenAI (or any OpenAI-compatible speech endpoint) | Speech | The exact line of dialogue or narration to be spoken |
| Stripe | Subscriptions and payment | Your email address, the team name, and the team id and slug. See section 6 |
| Expo push service | Mobile notifications | Your push token and the notification itself — the title contains the project title, and a failure notice contains a truncated error message |
Two exceptions worth naming: Stripe is credential-gated like the rest, **but the push service is not** — as long as you have registered a mobile device and enabled notifications, it gets a message when a film finishes or fails. Removing the device stops it.
One shot may be sent to more than one vendor
Routing and fallback both happen per shot. When a vendor fails or refuses, the same shot description goes to the next vendor and is tried again. So the answer to “where has this text been” can be more than one name. Every attempt, including the failed ones, leaves a line in the usage records.
Drafts are not sent anywhere
Draft quality is forced onto the built-in implementation: the picture is a concept board drawn locally with Pillow and ffmpeg, and with no speech vendor configured the voice track is synthesised locally or left silent. The rounds you spend reworking the storyboard send nothing out. Text works the same way — with no routing service configured, a built-in template implementation runs locally and nothing leaves the machine.
Your content crosses borders
These vendors' endpoints sit in different countries. Some Alibaba Cloud and Volcano Engine endpoints are in mainland China; xAI, Google, OpenAI and Stripe are in the United States; our own servers are in Australia. Your content therefore crosses borders, and which jurisdictions it passes through depends on which vendors are enabled at the time.
We tell you plainly where the data goes. We draw no compliance conclusions from it — what your local law requires, and whether your particular use needs anything further, is covered in section 13.
What vendors do with it afterwards is governed by their terms
What we control is what gets sent, to whom, and when. Once content reaches a vendor, how long it is retained and whether it feeds model improvement is a matter for that vendor's own terms — we have not negotiated separate use restrictions, and we hold no written “not used for training” commitment from any of them. If that matters to your project, read their terms before putting sensitive material in.
6Payment#
We never touch your card number. Payment happens on Stripe's hosted checkout page, which is not ours. Card number, expiry and CVC never pass through our backend — there is nowhere in the code that could receive them. Changing a payment method or retrieving an invoice goes to Stripe's billing portal, which is also theirs.
| Detail | |
|---|---|
| What we send Stripe | Your email address, the team name, and the team id and slug, so payments can be matched to an account |
| What we keep from Stripe | Customer id, subscription id, subscription status, and the end of the current billing period |
| What we can never see | Card number, expiry date, CVC, billing address |
Subscription state is driven by webhooks Stripe sends back. That endpoint verifies the signature: with no signing secret configured it refuses to process anything, and a bad signature is rejected. It also de-duplicates by event id, so a redelivery cannot grant the same credits twice.
As the payment processor, Stripe handles what you enter on its pages under its own privacy policy.
7Where it lives and how long it stays#
| What | Where | Protection | Retention |
|---|---|---|---|
| Database — accounts, projects, scripts, usage | AWS RDS PostgreSQL, ap-southeast-2 (Sydney, Australia) | Encrypted at rest (AES-256), not reachable from the public internet, connectable only by the application containers | No automatic clean-up — kept until deleted |
| Media files — video, audio, stills, masters | AWS S3 in the same region, delivered through CloudFront | Encrypted at rest (AES-256). The bucket blocks all public access; only the CDN can read it | Automatically deleted after 90 days — see below |
| Database backups | AWS automated snapshots, same region | Encrypted with the database | 7 days |
| Application logs | AWS CloudWatch, same region | AWS account permissions | 30 days |
| Marketing site | Cloudflare Pages | Static files only; contains no user data | — |
Media files are deleted automatically after 90 days
There is a lifecycle rule on the object store: media expires 90 days after it is written — shot clips, voice-over, reference stills, and also your finished MP4 and any music you uploaded. Projects, scripts and storyboards in the database are unaffected and stay. So after 90 days an old project still has its words, but the film can no longer be retrieved. Download anything you want to keep.
Those 90 days are a lifecycle rule on the object store, not a retention commitment: we have neither undertaken to keep media for at least 90 days nor undertaken to delete it on the 90th. If the figure changes, section 14 applies.
9Deletion: what actually goes#
This is the easiest section in which to write something flattering. Here is what really happens.
| What you delete | What is genuinely removed | What stays |
|---|---|---|
| A project | The project and all of its episodes, scripts, shots, assets, master records and stage records — cleared from the database | Media files are not deleted. Clips, voice-over, reference stills, posters and the finished MP4 all remain in object storage until the 90-day lifecycle rule expires them. Usage records and any feedback you left also stay — neither is attached to the project in a way that cascades |
| Music uploaded to a project | Both the database record and the audio file | — |
| A shot, an asset, a master | The database record | The corresponding media files remain in storage |
| A device (push) | The push token and the device record | — |
| An API key | The key record; it stops working immediately | — |
| A team member, an invitation | The membership or the invitation | Projects that member worked on still belong to the team |
| Signing out | That session record | Sessions on your other devices are unaffected |
There is currently no “delete my account”
No endpoint exists to delete an account or a team. That is a statement of fact, not an omission. For now, deleting your account and data means emailing us and having a person do it.
For those requests we do not state a turnaround time — committing to a number of days we cannot guarantee would be worth less than saying nothing. There is likewise no self-service data export; export requests go the same way.
10Who can see your material#
Other users: they cannot
All business data hangs off a team, and every endpoint fetches resources scoped to the caller's team. Another team's resource comes back to you as “does not exist”, never as “not allowed” — the second answer confirms the id exists, which is a channel for enumerating other people's work.
Your teammates: they can
Members of the same team share projects, masters and usage. Roles are owner, admin and member, which decide who can change billing and manage people. Inviting someone into a team gives them everything already in it — worth thinking about before you send the invitation.
Us: yes, but narrowly
Whoever operates the service has access to the database and the object store. That is true of every self-hosted service, and claiming otherwise would be dishonest. We use it to diagnose failures and to action requests you make. We do not use it to browse your work.
That access is currently held in check by convention rather than by mechanism: there is no tiered internal permission scheme, no approval step, and no internal access audit log. It is written down here because you are entitled to know what constrains “the operators can see it” — and at the moment what constrains it is not the system.
11We do not train on your work#
We train no models at all. What we do is orchestration: arranging external vendors' capabilities into a line that delivers. So “using your content to train our models” is not something that can happen here — there is nothing to train.
Nor do we do anything else with it: no selling, no sharing with advertisers, no use beyond making your films and billing you for them. The line does produce model scoring data, but it is built from usage records — which vendor, how many seconds, succeeded or failed, how long it took — and contains none of your text.
External vendors are outside our control, though
See the last part of section 5: once content has been sent, what happens to it is governed by each vendor's terms, and we hold no “not used for training” commitment on your behalf.
12Children and young people#
The product is built for adult professional creators. We do not ask for age at sign-up, and there are no features or protections aimed at younger users. The age at which someone can consent for themselves differs by jurisdiction — 13 in some, 14 or 16 in others — and we have adapted the product to none of them. That is the same point section 13 makes.
13What we can and cannot say about compliance#
The most misleading thing a privacy policy can do is drop “we are GDPR compliant” into a footer. So, plainly:
- We do not claim compliance with the EU GDPR. There is no data protection officer, no data protection impact assessment, no EU representative, and no transfer mechanism such as standard contractual clauses in place.
- We do not claim compliance with the CCPA/CPRA in California, and have not assessed the product against it.
- We do not claim compliance with China's Personal Information Protection Law. No cross-border security assessment, no standard contract, no personal information protection impact assessment — and as set out above, data does cross borders.
- We hold no security certification — no SOC 2, no ISO 27001.
- We have no data processing agreement available to sign.
What we can do is set out the facts: the data sits in Australia, media expires after 90 days, logs are kept 30 days, content goes to the vendors listed above, and deletion leaves the things named in section 9. What your own law makes of those facts, and whether your use needs anything more, is for you or your legal advisers to judge. If your organisation needs a signed document today, we do not have one — and saying so is more use than hedging.
14When this document changes#
The version and the date sit at the top of the page. Substantive changes — a new category of data, a new vendor that receives your content, a shorter retention period — will be emailed to registered users and noted here. Wording fixes will not be announced.
If we ever add analytics or third-party cookies, this page and the cookie page change first, and the feature ships afterwards. In the other order these pages are decoration.
15Getting in touch#
Questions about data, and requests to delete or export it, go to [email protected]. Please include the email address on your account and what you are asking for.