Local data and storage
What Orneos keeps in your browser, how much space it uses, when it is destroyed, and why it is not a backup.
What is stored
A relational database inside your browser, holding your company’s data for the teams you belong to:
- Issues, projects, labels, board columns, saved views
- Your durable queue of changes not yet accepted by the server
- Replica metadata — which team is active, and your replay position per team
Plus small preference values: your theme, and a drafting key if you chose to remember one.
Vault page content is not stored locally. That is why Vault needs a connection.
Where it lives
In the browser’s origin-private storage for the Orneos origin, not in a file you can open. It is not visible in your filesystem and is not synced by your OS.
Tabs using the same origin and browser profile share one database through a shared worker. A different browser or profile is a separate client. Private modes may restrict the storage needed to start the app and should not be used for durable unsent work.
How much space
Proportional to your team’s data. It is not a cache with a size cap — it is a replica, and it holds what your teams contain.
If several teams are large, expect the background fill of other teams to add to that.
When it is destroyed
| Trigger | Effect |
|---|---|
| Signing out | Entire replica destroyed and storage wiped, including the queue. |
| Company access revoked | Runtime halted and full local reset attempted when revocation is detected; cleanup failure is reported. |
| Switching company | Same, but refuses to proceed unless it can prove the queue is empty and the wipe succeeded. |
| Data shape change after an update | Data tables rebuilt from the server. The queue is preserved. |
| Losing a team | That team’s rows purged. Other teams and the queue untouched. |
| You clear site data | Everything, including unsent work. |
| Browser eviction | Everything, including unsent work. |
The distinction in the last two rows from the first three is worth reading twice: the app’s own resets protect your queue except across a principal or company boundary, where destroying it is the point. The browser’s mechanisms protect nothing.
Eviction is a real risk, not a theoretical one
At startup Orneos requests persistent browser storage when supported. The request is best-effort and does not block startup; the browser may deny it or the request may fail. Persistence can reduce automatic eviction, but does not protect against manual deletion, private-session cleanup or every storage failure. Do not treat the local replica as a backup.
Practically: do not leave work queued offline for days.
This is not a backup
The local replica is a copy of what the server sent you, plus work that has not reached the server yet. It is not a backup of your account, and it cannot be exported or restored as one.
Data you can afford to lose lives here comfortably. Data you cannot should have an independent copy, made by you.
Resetting it
If the app is behaving strangely — stale data, something not appearing, a queue that will not drain — a reset is the blunt fix. It discards the local copy and re-downloads from the server.
A reset discards unsent work
Anything in the queue that the server has not accepted is gone. Reconnect and let the queue drain before resetting, unless the queue is precisely what is broken.
Steps are in Troubleshooting.
Related
- How sync works
- Offline and reconnect — how to tell whether anything is queued.
- Privacy and your data
Something here wrong, missing or out of date? Tell us at support@orneos.com — corrections to these pages are welcome and we would rather hear it than have you work around it.