One SFTP server, many customer organizations. Shared release areas, private customer uploads, ad-hoc patches per customer — with strict cross-tenant isolation.
You publish releases and patches to a growing list of customers. Some artifacts are public (every customer downloads the same release build). Others are customer-specific — a hotfix for one utility, a custom configuration for another manufacturer. And when customers push data BACK to you — support bundles, sensitive telemetry, config exports — that data must never be visible to another customer.
The simple "one home directory per user" model works when every user is your employee. It breaks the moment you have three customers who each want a private upload area, a shared read-only release directory, and an ad-hoc patch folder that only appears when there's a patch to deliver.
Rolling one server per customer is expensive to operate. Rolling one folder per customer with prefix-based ACLs is fragile — a config typo cross-exposes tenants. Rolling different user accounts per relationship is worse: a customer contact with access to two utilities you serve has to remember two logins.
You need a real identity model: organizations for tenants, groups for roles inside a tenant, and virtual folders for the shared and private spaces — all in one server, all in one admin console.
✗ One folder per customer — ACL sprawl
✗ Prefix-based paths — brittle isolation
✗ One server per tenant — expensive
✗ Ad-hoc patches — manual copy jobs
✗ No org-scoped audit view
✗ Cross-customer contacts — two accounts each
Model each customer as an organization. Model roles inside a customer (uploaders, downloaders, admins) as groups. Publish shared and private storage as virtual folders mapped to physical directories. Grant folder access to groups — and let users belong to groups across multiple organizations when a customer relationship requires it.
Three organizations share one server. Each virtual folder is granted to specific groups, so customers see only the folders they belong in. Vendor staff see everything.
The scenario below uses fictional names — Vendor Corp is the vendor running the server; Customer Alpha and Customer Beta are two of its customers. Real deployments follow the same shape with any number of customer organizations.
Vendor Corp is the operator organization — the vendor that runs the SFTP server. Customer Alpha and Customer Beta are customer organizations. Any number can be added later without server downtime.
Each virtual folder is a logical path (like /uploads-alpha/) mapped to a physical directory on disk. Folders are org-agnostic — who can reach them is decided by which groups you grant them to.
Groups are the ACL vehicle. Grants tie a group to a folder with a permission level (READ, WRITE, or READ_WRITE).
A user belongs to one or more groups. Membership can span organizations — a Customer Alpha contact who needs public releases joins the Vendor Corp public-downloads group AS WELL AS their own Customer Alpha / alpha-team group. Effective access is the union.
Virtual folders are surfaced per-channel via three independent toggles in the admin. Portal auto-enables the first time you grant a folder; SFTP and FTP are opt-in.
Each user's file listing at the SFTP root is the union of their home directory and every virtual folder any of their groups grants them access to.
| User | /downloads |
/uploads-alpha |
/patch23 |
/uploads-beta |
|---|---|---|---|---|
| Hana Vendor staff |
READ_WRITE | READ_WRITE | READ_WRITE | READ_WRITE |
| Alice Customer Alpha |
READ | READ_WRITE | READ | — not visible — |
| Bob Customer Beta |
READ | — not visible — | — not visible — | READ_WRITE |
Alice cannot list, traverse, or even see the existence of Bob's upload directory — the folder never appears in her file tree. When Bob is added to a new customer patch, a new virtual folder appears; when the patch is retired, the grant is revoked and the folder disappears from his view without a client restart.
Folder ACLs are enforced by the server on every file operation. A misconfigured client cannot browse another customer's folders because the server never surfaces them.
A customer contact working across two of your customer relationships logs in once and sees both. Group memberships span organizations natively — no duplicate accounts.
Need to deliver a hotfix to one customer? Create a virtual folder, grant it to the customer's group. Retire it later by revoking the grant — grants disappear from the client with zero disruption to unrelated sessions.
Every audit event is tagged with the affected organizations. Filter the audit trail by tenant to answer support and compliance questions instantly.
Vendor staff with the can_sign capability produce PGP-signed release artifacts directly from the Portal. Customers verify with the free bundled verifier tool downloaded from a public endpoint — no PGP tooling required on their side.
The server refuses admin changes that would give a user two different physical paths at the same logical name. Mount conflicts are caught before they hit an SFTP client.