Runs on a schedule
Cron-based recurring jobs and one-off runs, executed by a worker service that's separate from the admin interface — so the web app going down doesn't stop transfers, and a transfer storm doesn't take the admin interface with it.
Managed file transfer
Know what happened to every single file
Portari moves files between systems you don't control — a partner's SFTP server, a customer's FTP drop, a vendor's OneDrive tenant — on a schedule, unattended. Then it can tell you exactly what moved, what failed, and what became of the original.
Live
Self-hosted
Your servers, your network, your data
Three protocols
FTP, SFTP, and OneDrive via Microsoft Graph
Runs on Windows
SQL Server, MySQL/MariaDB, or PostgreSQL behind it
Per-file record
Every delivery, removal, and archive accounted for
How it works
One source, any number of destinations
A job draws files from one source and delivers them to as many targets as you like. Hosts, credentials, and profiles are reusable records, so an endpoint gets described once and referenced by every job that needs it.
Picks the right files
Per-profile file masks, glob or regex, with optional recursive directory walks that preserve the remote folder structure on the way out. What a target is owed is decided from what's been recorded about that target, not from what happens to be sitting in a folder.
Says what it did
A per-file record of every transfer, every removal, and every archive, each with its own outcome — plus an audit trail of who changed which configuration and when. Kept for a year by default, configurable, with per-profile overrides.
The rules it holds to
Silence is never success
Portari moves other people's files, unattended, with no undo. That constraint produced a short list of rules the product isn't allowed to trade away — not for throughput, not for a tidier design. These are the ones an operator feels.
A failure stops at the thing that failed
One unreachable server doesn't turn a fan-out into a partial delivery, and one unreadable file doesn't abandon the rest of the batch. Neither ends the run early — because work that was never reached leaves no record, and afterwards you couldn't tell it apart from work that had nothing to do.
Nothing gets delivered twice by accident
A file that's been delivered and accounted for isn't sent again on a later run. Re-delivery is something you ask for explicitly. A duplicate is a data problem, not an annoyance — a re-sent invoice can get paid twice.
An outage doesn't burn your retries
If a target isn't answering, the file was never offered to it, so the delivery waits instead of failing — it spends none of its attempts, and everything queued for that system goes as soon as it answers. Spending a file's three attempts on a server that's down declares it dead ten minutes into an outage that might last days.
Nothing is destroyed until its replacement is confirmed
Deleting or archiving the original is gated on the delivery actually having happened. A delivery that exhausts its attempts is marked exhausted, not discarded: the target is still owed the file, the staged copy is kept, and the original stays put until a person decides otherwise — with a reason, recorded.
It tells you when nothing happened
The failure that hurts most is the one where nothing ran and nothing said so. Portari watches for work it expected and didn't see — a schedule that stopped firing, a worker that stopped processing, a system that's been unreachable too long, a run that started and never reported an end — and emails about it without being asked.
Every alert clears itself when it stops being true, and the all-clear gets emailed too. Knowing a system came back matters as much as knowing it went away.
Running it
Self-hosted, and genuinely your control over files
Portari installs on your own Windows infrastructure — an admin interface and a worker service, against a database you already run. Files you're moving never pass through us, because there's no "us" in the path at all.
That suits the environments this kind of work tends to live in: a box inside your network, talking only to the endpoints you've told it about. Running Portari doesn't require opening outbound access to anything else.
- Protocols. FTP, SFTP, and OneDrive through Microsoft Graph — mixed freely within one job.
- Platform. Windows today. Linux support is in progress and not something to plan around yet.
- Databases. SQL Server, MySQL or MariaDB, or PostgreSQL. Pick the one your team already operates.
- Sign-in. Local accounts or LDAP, so operators use the credentials they already have.
- Add-ons. Local file encryption, LDAP, and OneDrive are licensed features — turn on what you need and leave the rest off.
Where the edges are
Same rule here as everywhere else on this site: you should be able to tell whether something fits before you pay for it.
- Windows only, for now. Linux support is being built and isn't finished. If you need to run this on Linux, ask where it stands rather than assuming a date.
- Single-tenant today. One organisation per install. Multi-tenancy is designed but not shipped, so a service provider runs an install per client.
- No public price list. Licensing is per install, and what you need switched on varies a lot. ROCI Solutions handles pricing and will tell you plainly.
- Three protocols, not every protocol. FTP, SFTP, and OneDrive are in. S3-style object storage and others are on the roadmap, not in the build.
- You run it, so you operate it. Self-hosting means patching, backups, and uptime are yours. That's the trade for your files never leaving your network.
Next step
Tell them what you're moving
Portari is sold and supported by ROCI Solutions, our delivery partner. Tell them what the systems are, how often, and what has to be provable afterwards, and they'll tell you whether Portari fits — including when it doesn't.