SFTP or a network share: setting up a SIS roster drop without a new server

You do not need a new server to give a vendor an SFTP drop. A roster feed needs a dedicated account, key-based login, an IP allowlist, a folder the account cannot climb out of, and a log you can show. All of that can sit in front of storage you already own.

The sentence every district hears

In a thread on r/k12sysadmin last week, titled “Infinite Campus and OneSync”, a commenter from a district starting its roster integration reported what their vendor had told them:

She told me we could do SFTP or a network share. Like those are our only 2 options. So we are trying to get the SFTP setup with our MSP.

That sentence is worth taking seriously, because it is the honest version of how most roster pipelines work. An SIS exports a file on a schedule. A downstream system picks the file up on a schedule. Everything in between is a place to put the file. A flat file you can open and diff is not a step backwards.

So the real question is the one the commenter is now paying an MSP to answer: what is the cheapest safe way to stand up that drop?

A network share is the right answer when both ends are inside your network. A roster feed rarely is. One end is the SIS vendor’s cloud, writing the extract, and the other is a sync tool that may also be hosted elsewhere. Getting an outside party onto an SMB share means a VPN or a firewall exception, a service account on your domain for someone else’s software, and share permissions that are easy to over-grant and hard to audit afterwards. None of that is wrong. It is just more surface than a file drop deserves.

SFTP is the right answer when either end is outside. It is encrypted, it works over a single port, it is the delivery option vendors most commonly offer for this kind of feed, and it comes with the two controls you most want for a vendor account: a key instead of a password, and a source-address allowlist. The catch is where it runs. The traditional answer is a VM in the district data centre or a cloud account, with OpenSSH or a commercial server on it, and that VM becomes one more thing with a patch cycle, a certificate, a backup and an owner.

The point of this article is that the VM is optional. You can have the SFTP account without the SFTP server.

What a roster drop needs

Whatever you build it on, the drop should give you these. They are the things an auditor, or you in six months, will ask about.

A dedicated account per integration. The SIS export gets its own login. The sync tool gets its own login. Neither is a human’s account, and neither is shared with the next vendor. When one is retired, you delete one user and nothing else changes.
Key-based login where the sender supports it. Infinite Campus documents an SFTP delivery mode for its Data Extract Utility and a key exchange tool so the delivery authenticates with a key pair rather than a stored password. Use it. A password in a vendor’s configuration screen is a password you will never rotate.
An IP allowlist. The SIS writes from a known set of addresses. The sync tool reads from another. Nothing else on the internet needs to reach the account, so nothing else should be able to try.
A folder the account cannot climb out of. The export account sees one folder, the import account sees the same folder, and neither can see what any other integration is dropping. On a shared server this is the chroot or home-directory problem, and it is the step people get wrong.
A log you can show. Which account connected, from which address, what it uploaded or downloaded, how many bytes, when. The day the import “mysteriously” stops, this is what tells you whether a file arrived at all.
Keep the files. A roster extract is small. Keep a few weeks of them. When Tuesday’s import is missing students that Monday’s had, the diff between the two files is the fastest diagnosis available.
Nothing new to patch. If the drop needs its own operating system, it needs its own owner. Districts are short of those.

One mailbox, two accounts

The shape that satisfies the list is a single folder in storage the district already owns, with two accounts on it.

Account	Used by	Home directory	Access	Login
`sis-export`	Infinite Campus Data Extract Utility extract	`/roster`	Read and write	SSH key from the SIS’s key exchange, IP allowlist
`sync-import`	The downstream sync tool	`/roster`	Read only	SSH key or password, IP allowlist

Both accounts land in the same folder, so there is no copy step and no second place for the file to be stale. The writer cannot read anything outside the folder. The reader cannot write at all, so a misconfigured sync tool cannot delete or overwrite the extract. The folder lives in a bucket in the district’s own cloud account, which is where the retention and the backup come from: turn on versioning and a lifecycle rule and the storage keeps a few weeks of extracts without anyone running a script.

If the district already has Microsoft 365, the natural home is an Azure storage account. If it runs Google Workspace, a Google Cloud Storage bucket. Either way the files stay in the tenancy the district already governs, which is the right place for student data to be.

Setting it up

Here is the sequence on DocEvent’s Simple FTP Service, which is a managed SFTP and FTPS endpoint in front of your own bucket. There is no server to provision. Capabilities are as of October 2026.

Create a service over your bucket. Pick the region closest to the district and point the service at an Azure Blob or Azure Files container, a Google Cloud Storage bucket, an S3 bucket, or an S3-compatible store. Give DocEvent scoped credentials to that one container, not the whole account. The guides for Azure, Google Cloud and S3 walk through the storage side.
Add the export user. On the service’s Users tab, add sis-export with a home directory of /roster. The home directory is a hard boundary: paths are cleaned before they are joined to it, so a client sending ../ ends up back inside its own folder. Open the user’s Authorized keys panel and paste the public key the SIS’s key exchange tool gives you. Up to ten keys fit per user, so a key rotation is an add-then-remove, not an outage.
Add the import user. Add sync-import with the same home directory and make it read-only. Give it a key if the sync tool can present one, or a long generated password if it cannot.
Set the allowlist. On the service’s Firewall tab, add the SIS vendor’s outbound addresses and the sync tool’s. Ask each vendor whether it can give you stable egress addresses or ranges before you rely on the list. Once the allow list has any entry, every other address is refused before it can try a password.
Test from your own machine first. Temporarily add your own address to the allowlist and connect as each user. The login is serviceid/sis-export on port 22 at sfs-<region>.docevent.io. Confirm the export user can write to / and sees nothing else, and that the import user can read but not write. Then remove your address.
Point the vendors at it. Give the SIS the hostname, port 22, the serviceid/sis-export username and the key, and give the sync tool the sync-import login and the same path, following each product’s own documentation for where those go. If a vendor’s form refuses a slash in the username, there is a documented workaround.

That is the whole build. An MSP can do it in an afternoon, and the district can read every setting back in the console afterwards, which matters when the MSP contract ends.

Day two: when the import breaks

The problem you will actually have looks like this. Some students sync, some do not, the SIS says it is sending them, the sync tool says it should be working, and nobody can show the other side a file. With a drop you own, the questions get shorter:

Did a file arrive? The service log lists every upload by sis-export with a timestamp and a size. No entry last night means the problem is on the SIS side, and you can say so with a screenshot.
Did the sync tool collect it? The same log shows the download by sync-import. A file that landed and was never fetched is a scheduling or credentials problem on the import side.
What changed between the file that worked and the one that did not? With bucket versioning on, both files are still there. Diff them. A missing attribute on a newly entered student is the usual culprit, and a diff of two rows finds it in a minute.

To be clear about what this does not do: DocEvent moves and logs the file. It does not parse OneRoster, validate rows, or explain why a sync tool rejected a record. It gives you the evidence to have that conversation with the vendor who should.

What it costs

A roster drop is two users and a few megabytes a night, so it sits at the bottom of the pricing page. The Basic plan is free for up to five users but does not include the firewall, SSH keys or log retention, so it is for trying the shape, not running it. The Standard plan starts at $10 a month and adds the allowlist, key authentication, 30 days of searchable logs and a 99.9% uptime SLA. Longer log retention and file restore from the console are on the Premium plan. For a K-12 reader working out what to tell the business office: less than the licence for one more Windows Server VM, and nothing for the MSP to patch.

Stand up the roster drop this afternoon

Managed SFTP over the storage account your district already has. Two users, a home directory, SSH keys and an IP allowlist, with a log you can show the vendor. No VM.

Get started free Ask us about SIS feeds

Student roster files are personal information under FERPA and your state’s student-privacy law. Keeping the files in the district’s own storage account and scoping each vendor’s access to one folder supports those obligations; your agreements with each vendor complete them. This article is general information, not legal advice.

References

Infinite Campus and OneSync - r/k12sysadmin, September 2026. The thread this article is written from, including the “SFTP or a network share” comment.
Data Extract Utility SFTP Key Exchange Manager - Infinite Campus Knowledge Base. Key-pair authentication for Data Extract Utility extracts delivered over SFTP.
Home directories and keeping each user isolated, SSH authorized keys for passwordless SFTP, IP allow and deny lists and File versioning and restore - DocEvent support guides for each step above.