Halaman ini belum tersedia dalam bahasa Anda. Anda membaca teks bahasa Inggris.
Session sync
Your session on two computers
- scrypt plus AES-256-GCM
- Encryption
- your folder, not ours
- Storage
- 1 / 2 / 5 / 20 by plan
- Device seats
- 3 minutes, renewed while open
- Profile lock
Where accounts get lost
Profile settings travel through your account: name, scenario, fingerprint template, proxy, group, tags. Cookies, logins and site storage do not, because they sit in the profile directory on the machine that made them.
So an honest move to a second computer means signing in to thirty accounts again. The shortcuts are worse: a hand-copied profile folder gives a broken database, and one account open in two browsers at once is the pattern that gets it reviewed.
ARMANOS answers that in two halves. A session travels as one encrypted file through a folder you already own, and a profile opens on one machine at a time.

Your folder your cloud
You point ARMANOS at a folder on the Engine screen, in the Sessions on two computers, through a folder block, and anything your own cloud already syncs will do. A cloud drive, a work network share, a folder on a NAS: the app does not know which one it is and does not ask.
That is a deliberate choice. We run no storage for your sessions, so there is nothing of yours for us to hold, lose or hand over.
- 1
Choose the folder
Any folder your cloud syncs. The app writes a probe file first, because a share can look available and refuse the first real write.
- 2
Set a passphrase
The Passphrase for the sync files field: at least 8 characters, and the same on both machines.
- 3
Name this computer
That name is what the other machine shows you when a session arrives from here.
- 4
Turn on Sync sessions
Without a folder and a passphrase the switch refuses, instead of saying on and doing nothing.
What travels and what does not
Two files per profile appear in your folder: the encrypted archive and a small plain label the other machine reads first. That archive holds the sessions of both engines in one file.
Alongside them goes the profile itself, with its id. The id travels because the fingerprint is derived from it. The browser version of a profile without a pinned kernel comes from the computer, so keep the app updated on both and use the same engine on both.
The cache stays home deliberately. Caches, shader caches, worker storage and crash dumps are hundreds of megabytes that sites refill by themselves. The components the engine downloads for itself, such as speech voices, stay home too: it downloads them again on the other machine.
| What | Does it travel? |
|---|---|
| Cookies, logins, local and IndexedDB storage | Yes, inside the encrypted archive |
| Profile id, name, scenario, group, tags, notes, opening address | Yes, as profile.json inside the archive |
| Fingerprint template, generation and manual edits | Yes, and the id with them, so the fingerprint stays the same |
| Proxy, country, 2FA secret, saved login | Yes, and only inside the encrypted file |
| Which extensions are switched on | Yes, the choice; the files themselves are not packed |
| Caches, worker storage, crash dumps, lock files, engine components | No, sites and the engine refill them, and the file would be unliftable |
| The profile's name, outside the encrypted file | No, the label holds time, size and your computer's name |
One passphrase on both machines
The file here is the one the manual profile transfer already uses, so you open by one route what you wrote by the other. A header, a random 16 byte salt, a 12 byte nonce, scrypt with N 32768 to a 256 bit key, then AES-256-GCM.
A wrong passphrase gives you an honest refusal rather than garbage, because the file carries an integrity tag. The passphrase is kept on this machine and the app says so on screen: asking for it at every close would mean no automatic upload at all.
Where your passphrase lives
On Windows the system seals your passphrase with a key tied to your Windows account. On macOS it is sealed with a key that ships inside the program, and on Linux it goes as typed into a file readable only by you, so on both it does not protect against anyone who can read your user folder. It never enters the sync folder and never comes back to the screen.
File permissions are a macOS and Linux fact
When the exchange happens
Before a profile opens, the app takes a newer session from the folder. It has to be before the window exists: replacing files under a running browser leaves a broken profile.
Four seconds after a profile closes, the session is sent: a browser keeps writing its databases for a second or two after the window disappears, and the app checks again that the profile is still closed. If you quit ARMANOS or install an update while profiles are open, the app asks first. Save and close waits up to a minute for the sessions to reach the folder, and Close without waiting closes at once and sends them at the next start.
What only happens when you say so
While the app is open it watches the folder once a minute, reading one timestamp rather than every label. It never pulls silently, because someone else's session arriving in a profile you are working in would swap the ground under you.
Send mine to the folder
Per profile, with a confirmation that says plainly it replaces what is there.
Take the one from the folder
Per profile, replacing the session this computer holds for it.
Send all and Take all
One after another: thirty simultaneous writes into a cloud folder invite duplicate copies.
When both sides changed
The app decides by marks rather than by clocks. It asks whether this machine's session changed since the last sync and whether the folder's label did, so two clocks on two machines never enter it.
If both changed, two people worked in parallel and either write would throw away real logins. So nothing travels in either direction, and you get a notification naming the other computer, a mark on the row and two buttons in the profile card.
Send mine to the folder settles the argument for this machine. What you replace is copied aside first and the last three copies are kept, so a click made without thinking costs a minute rather than a day of work.
| State since the last sync | What the app does |
|---|---|
| Nothing in the folder for this profile | Sends as soon as there is a real session to send |
| Only this machine changed | Sends |
| Only the folder changed | Takes it, before the profile opens |
| Neither changed | Nothing is written |
| Both changed | Nothing is touched; you are told and you choose |
| Label is newer than the file beside it | Nothing this round; the app comes back when the file arrives |
Clouds work behind your back
A cloud copies files one at a time, and the small label beats the big archive. So the app checks the size on disk against the size the label promises, and a pair that disagrees is left alone.
A missing archive is not an empty folder either. Space-saving modes take file contents off the disk and leave a stub, so the rule is simple: a label means a session exists.
The app lays a new archive beside the old one and renames it only then, because half an archive on top of a working session cannot be decrypted. Once an hour it sweeps leftovers older than an hour whose name is exactly its own, and never touches anybody else's file.
| What the cloud did | What you get |
|---|---|
| Copied the label first, the archive later | Nothing this round, then a normal take once the file lands |
| Evicted the archive to save disk space | Nothing is taken and nothing is overwritten |
| Kept two copies after a near-simultaneous write | The second copy is recognised by name and reported to you once |
| Left a half-written neighbour file behind | Swept after an hour, and only if the name is ours exactly |
One machine at a time
An open profile is left alone in both directions, because a copy taken mid-write is a broken profile on the other computer. The batch buttons skip open profiles too and tell you how many.
When you are signed in, an open profile also holds a lock on the server. A second machine is refused by name, and you can take the profile over on purpose.
Each of your computers gets a random identifier of its own, so two laptops with the same name are two machines. Your seats are a workspace pool that follows the live subscription, and unlinking a machine frees its seat at once.
- Lock held for
- 3 minutes
- Renewed
- every 60 seconds while the profile is open
- Second machine
- refused, and told who holds it and since when
- Profile closed
- the lock is released at once
- Machine unplugged
- the lock expires on its own
These are the same numbers the profile lock on the server and the renewal in the app hold.
| Plan | Device seats | Profiles |
|---|---|---|
| Free | 1 | 2 |
| Professional | 2 | 10 to 100 |
| Business | 5 | 200 to 1000 |
| Enterprise | 20 | 5000 and above |
What this does not do
- It does not host anything for you. No folder, or a cloud app that is not running, means no exchange. If your cloud has not finished copying, the app waits and does nothing that round.
- It does not merge two sessions. When both sides changed you pick one, the other is set aside as a copy, and putting the two together is manual work.
- It does not touch an open profile in either direction. A profile you keep open all day does not travel until you close it.
- It is not live mirroring. Sessions move before a profile opens, a few seconds after it closes, at app start, and when you press a button.
- If you lose the passphrase, the files already in the folder cannot be opened. There is no recovery path, by design: we hold no copy of it.
How to check
Every claim above has a file behind it, and most have a stand that runs the real code.
- The folder gets an encrypted file, and a full round trip restores the cookies
- apps/desktop/src/lib/sessionSync.js · apps/desktop/test/session-sync-folder.js
- Both sides changed: nothing is overwritten, and what you replace is kept aside
- apps/desktop/src/main/main.js · apps/desktop/test/conflict-keeps-copy.js
- An archive the cloud evicted or has not finished copying is not read as an empty folder
- apps/desktop/src/lib/sessionSync.js · apps/desktop/test/cloud-evicted-file.js
- One profile opens on one machine at a time, and takeover is deliberate
- apps/server/src/profiles/profiles.service.ts · apps/server/test/profile-lock.js
- Seats follow the live plan, and unlinking a machine is remembered
- apps/server/src/devices/devices.service.ts · apps/server/test/team-money-seats.js · apps/desktop/test/device-identity.js
Questions
- How large can one session archive be?
- An archive over 400 MB comes back to you as a refusal rather than half a file. That is why caches and crash dumps leave the archive first: they are hundreds of megabytes a site refills by itself.
- Can I pick up a profile that exists only in the folder?
- Yes. Find profiles in the folder shows you what is in the folder but not here, and the settings come from inside the archive, so it works with no account at all.
- What happens when I change the sync passphrase?
- Each of your profiles travels again under the new passphrase, and the app tells you how many. Otherwise the folder quietly fills with a mixture of two passphrases.
- Does anything about my sessions reach your server?
- One line, and only after the work is done: which machine, which direction, whether it worked, and a short error name. No file names and no contents, and without it your dashboard would show nothing about sessions at all.
- What if I close the app before a session is sent?
- The app catches the send up at the next start, one profile at a time with a pause between them. Building thirty sessions at once would freeze the machine right after launch.
Read next
Profiles
What a profile holds, and why the session lives on the machine.
Transfer with the session
The same sealed file, carried by hand instead of through a folder.
Team
Shared profiles, roles, and the seat pool the whole workspace draws on.
Security
Where secrets are kept, what leaves the machine, and what does not.
Set it up on both computers
With ARMANOS on both machines, point both at the same folder and set the same passphrase. The first session travels the next time you close a profile.