Theme
Site settings
Site settings has eight tabs. Every one of them saves independently, so you can change one panel without touching the others.
Changes are delivered to your site immediately. Where a setting refuses something, it refuses new sign ins from that moment; transfers already running are not interrupted unless the page says so.
Addresses and domains
Your platform address
Your site's permanent address, in the form yoursite.on.sftp.cloud.
This address always works, and it is where SFTP and FTPS clients connect. It is never affected by anything you do with custom domains.
Your own domains
You can point your own domain at your site, for example files.yourcompany.com.
Custom domains serve the web client only
SFTP and FTPS resolve which site you are on from the username, not from the hostname, so they always use the platform address. A custom domain gives your users a branded web address in the browser; it does not give you a branded SFTP hostname.
To add one:
- Choose Add a domain and type it.
- The page then shows two options. Pick the one that matches your domain and publish only that option's records.
- Choose Verify.
- Once DNS resolves, the certificate is issued automatically and the domain goes live within minutes.
Option 1: a subdomain, one CNAME record
For a name with a subdomain, such as files.yourcompany.com.
| Record | Name | Value |
|---|---|---|
| CNAME | the domain you added | the CNAME target the page shows |
The CNAME does both jobs at once: it proves the domain is yours and it routes the traffic.
Option 2: an apex domain, TXT plus A records
For a bare domain with no subdomain, such as yourcompany.com, where DNS does not allow a CNAME. Publish both:
| Record | Name | Value |
|---|---|---|
| TXT | _sftpcloud-challenge.yourcompany.com | the token the page shows |
| A | yourcompany.com | the IPv4 address the page shows |
| AAAA, optional | yourcompany.com | the IPv6 address the page shows |
Without the A record the domain can verify and will never load. The TXT record proves ownership; it routes nothing.
Status
| Status | Meaning |
|---|---|
| Waiting for DNS | Added, records not seen yet |
| Verified | Ownership proven, certificate being issued |
| Live | Serving |
If verification says DNS does not point at us yet, that is usually propagation. Wait a few minutes and try again.
Removing a domain stops it working for your site immediately. Your platform address is unaffected.
Protocols
Four switches: SFTP, FTPS, FTPES, Web browser access.
Switching one off refuses new sign ins over it immediately.
This is the site wide allowance. It combines with each user's own list on Users: a user may use a protocol only if both allow it. Turning one off here overrides every user.
Plain, unencrypted FTP is never offered on any plan.
Web client
Look and feel
What your users see on the web client sign in page and in their browser tab.
| Setting | Notes |
|---|---|
| Title | Replaces the default name in the tab and on the sign in page |
| Logo | An image no larger than 200 KB |
| Background, primary, secondary, tertiary accents | Light theme and dark theme, all optional |
| Privacy policy link | A full https:// address on your own domain, shown as a link on the sign in page |
Anything left empty keeps the stock look. Dark theme accents left empty are derived from your light ones. Setting a background also recolors the matching surfaces and borders automatically, keeping text readable.
Your brand, not ours
The web client your users see carries your branding. It is not a co-branded surface, and your end users need never know which service is behind it.
Privacy policy link
Under privacy law, the people who sign in to your web client are your users, and you are the one who owes them a notice explaining how their data is handled. The privacy policy link is where they read it: when set, the sign in page shows a "Privacy policy" link that opens your page in a new tab. Leave it empty and no link is shown.
The address must be a complete https:// URL on a public host name, for example https://www.example.com/privacy. Plain http:// addresses, IP addresses and internal host names are refused when you save. The web client only links to the page; it never loads anything from it.
No cookie banner needed
The web client sets no analytics or advertising cookies and loads no third party scripts. The only things it keeps in the browser are what a sign in needs: the session itself, the "remember this user" and "trust this device" choices your users make, and their view preferences. Those are exempt from consent requirements, so your users see no cookie banner, and the privacy policy link is the one notice the page carries.
File sharing defaults
Site wide rules for share links your users create.
| Setting | Effect |
|---|---|
| Sharing enabled | Off means nobody on this site can create a share link |
| Upload (drop box) shares allowed | Whether a share may accept uploads |
| Shares must have a password | Forces a password on every share |
| Longest share expiry, days | 0 means no site cap |
Individual users can be restricted further in their own profile, never loosened beyond this.
Identity provider
Connects the site to your organization's OpenID Connect provider (Microsoft Entra ID, Google Workspace, Okta, or any other), so your people sign in to the web client with the account they already have. It has its own page: Sign in with your identity provider.
Protection
Who may connect, and what your server does about the ones that misbehave.
Countries
| Setting | Effect |
|---|---|
| Refuse these countries | Two letter country codes. Sign ins from them are refused |
| Only allow these countries | When set, every country not listed is refused. Leave empty to allow all countries not refused above |
Country rules are checked when a user signs in, and they need our location database. Where a source cannot be located, the rules do not apply to it.
The three network lists
Three lists, one meaning each. The words mean the same thing everywhere in SFTP.cloud.
| List | Meaning |
|---|---|
| Deny list | These addresses are always refused, whatever else you set |
| Allow list | While it is empty, anyone may connect. Add one address and only the addresses on it may connect |
| Safe list | These addresses are never banned by the protection. Being on it does not let an address in |
Add a single address (203.0.113.7) or a whole range (203.0.113.0/24). Your list is stored in the form your server matches by, so 203.0.113.7 is shown back to you as 203.0.113.7/32.
An allow list is the whole guest list
Everything not on it is refused, including your own users away from the office, and anyone you have sent a share link to. A share recipient is judged by these lists exactly like a user signing in, so a partner who is not on your allow list cannot open the link you sent them.
The safe list never grants admission. An address on your safe list that is not on your allow list is still refused, and one on your deny list is still refused. Safe means "never banned", nothing more.
Where the lists take effect, and why the plans differ
This is a real difference between the two plans, and it comes from how the protocols work rather than from what we chose to sell.
On a shared plan your site shares a server with other customers. When a connection arrives, the server knows the address it came from and nothing else: SFTP and FTPS do not say which site they are for until a username is offered. So your lists are applied when a user signs in, against the site their username names. Your rules never reach anyone else's users, and theirs never reach yours.
On that plan the safe list means: your own users' failed sign ins from these addresses never count toward a ban. That is the honest limit of it. It cannot stop a ban that another customer's traffic earned from the same address, because that ban belongs to the machine.
On a dedicated plan the server is yours alone, so your lists are the machine's. The deny and allow lists are applied at the door: a refused address is turned away before any handshake, before it is shown your certificate, and before your server spends anything on it. Your safe list becomes a real exemption from banning, and you can lift a ban yourself. The sign in check still runs underneath, so both agree.
| Shared plan | Dedicated plan | |
|---|---|---|
| Deny and allow lists | Applied at sign in | Applied at the door, and again at sign in |
| Safe list | Stops your own failures counting toward a ban | Never banned, and adding an address lifts any standing ban |
| Lifting a ban yourself | Not available | Available |
| Strikes and ban length | Platform values | Yours to tighten |
| Addresses per list | 64 | 10,000 |
Currently banned
The addresses your server is refusing right now.
On a shared plan you see the bans earned against your site. Bans that protect the whole platform protect you too and are not listed, because they are not yours to see or to lift.
On a dedicated plan you see every ban the machine holds, including the ones earned before any sign in (marked Head wide: a protocol probe, or a run of connections that never authenticated), and each row offers two actions.
| Action | Effect |
|---|---|
| Lift | The address can connect again immediately. If it misbehaves again it is banned again |
| Lift and always allow | The ban is lifted and the address joins your safe list, so it is not banned again |
How your server responds
Dedicated plans only
Strikes before a ban and Ban length in minutes shape how the whole machine reacts, so they exist only where the machine is yours. On a shared server one customer's hair trigger would ban an address for every site on it.
To get them, see Moving to a dedicated server.
Both can only make your server stricter than the platform default: a lower threshold and a longer ban are applied, a looser value is ignored. Zero keeps the platform value.
Policy
Rules that apply to this site on top of the platform defaults. A zero means the platform value applies unchanged.
Sessions
| Setting | Effect |
|---|---|
| Idle timeout, minutes | Sessions with no activity end after this. Can only shorten the platform window |
| Default sessions per user | Caps concurrent sessions for users with no cap of their own |
Password rules
| Setting | Effect |
|---|---|
| Minimum length | Applied when a password is set or changed in the user editor |
| Required character classes | How many of lowercase, uppercase, digits and other characters a password must mix |
Existing passwords are not affected until they are changed.
Transfer speed
Per session caps in KiB per second for every user of this site. Where a user also has a cap, the stricter value wins. Zero means no site cap.
Sign in security
Refuse password sign in for every user.
Read this before turning it on
With this on, passwords are refused on every protocol, including the web client. Users sign in with an SSH key on SFTP, or a passkey in the web client.
An authenticator app does not satisfy this. A six digit code is only ever asked for after a password succeeds, and this setting refuses the password first.
Make sure your users have a key or a passkey registered before turning it on, or you will lock out everybody at once.
Let WebClient users reset a forgotten password by email. Off by default.
With this on, the web client's sign in page shows Forgot your password?. A user enters their username; if the account has an email address on file, is active, signs in with a password rather than through your organization, and is allowed on the web client, a message goes to that address under your site's name with a link that works once, for thirty minutes. The link opens a page that asks for the new password twice. A user with an authenticator app is asked for its code, or a recovery code, on that same page, and five wrong codes end the link. The link never signs the user in, and a passkey is still asked for afterwards. The page answers the same way whatever username is entered.
A mailbox becomes worth an account
Anyone who can read a user's mailbox can choose that user's password, unless the user has an authenticator app, whose code the reset page demands. A passkey protects the sign in but not the password; a user with only a password is as safe as their inbox. Turn this on knowingly, and prefer an authenticator app for everyone.
Every change a user makes, through this link or from their own settings, is confirmed by a message to their address under your site's name. It carries no link, only when and from where the change was made, so a change the user did not make does not go unnoticed.
Requests are limited to three per account and thirty per site in an hour. It is unavailable while Refuse password sign in for every user is on, because no password is accepted then anyway. The users who are mailed show up in your activity as a password reset link was mailed to a transfer user at their request.
Messages
Texts the FTPS service shows your users. Leave a field empty to keep the standard wording. Line breaks are preserved.
| Message | When it is shown |
|---|---|
| After a successful sign in | Right after a user signs in over FTPS |
| After a refused sign in | When an attempt is refused. The reason is never included |
| On goodbye | When a user ends the session |
The goodbye text is shown on dedicated plans only. On a shared plan the standard goodbye is used, because that message belongs to the whole server rather than to one site.
Advanced
Read only facts you may need to give partners or auditors.
| Fact | Use |
|---|---|
| Region | Where your site runs |
| Tier | Shared or dedicated |
| SSH host key | The fingerprint. Publish it to your transfer partners so they can verify they are talking to your site |
| Listeners | The ports your site is actually serving, read live |
The host key fingerprint is the one thing on this page worth handing out proactively. An SFTP client that has never seen your site has no way to tell the real one from an impostor except by comparing that fingerprint.