I just started using FileZilla client for a few client sites and I keep seeing people mention the “Site Manager” instead of just typing the server address at the top every time. What is it exactly and how does it work? Also is it actually safe to save my passwords in there, since I manage a handful of paid hosting accounts and don’t want to mess that up
The Site Manager is basically a built in address book. You save each server’s host, username, password, and connection type (FTP, SFTP, or FTPS) as an entry, then just double click it to connect instead of retyping everything. There’s a quick explanation of this on the FileZilla forum. It’s great once you’re juggling more than a couple servers, and you can organize entries into folders.
The catch is passwords are saved in plaintext in a local file, not encrypted, which people have debated for years on the forum. If that’s a concern, turn on “do not save passwords” under Settings, Interface.
Also worth knowing, FileZilla can’t sync that Site Manager file through a cloud drive on its own. There’s a thread where someone wanted it stored on Google Drive and had to edit a config file manually. Tools like CloudMounter, which mount cloud storage as a normal local drive, make that kind of setup easier since the folder just behaves like part of your file system.
So overall, it’s a big time saver and easy to use, just be mindful of the plaintext password storage on shared computers.
12 Likes
For one server you visit occasionally, Quickconnect is probably enough. For several servers, Site Manager is worth using because each profile can remember more than the address and username. You can set the protocol, port, default local and remote folders, connection limits, and other per-server options. That reduces the chance of connecting to the right server and then uploading into the wrong directory.
I would push back slightly on the claim that saved passwords must remain plaintext. FileZilla does store them insecurely if you choose ordinary password saving, but current versions offer master-password protection that encrypts stored credentials. You can instead disable password saving entirely. A master password is the reasonable middle ground on your own protected computer, while “do not save passwords” makes more sense on a shared or loosely managed machine.
The profile itself does not make an FTP connection secure, though. Use SFTP or FTPS when the server supports it, verify unexpected host-key or certificate warnings rather than clicking through them, and treat exported Site Manager files as sensitive. Site Manager is a solid convenience feature, but its safety depends on those choices.
The plaintext-password claim in the second reply is outdated unless you deliberately select the unprotected password-saving option. Current FileZilla versions can encrypt saved credentials behind a master password. That is much better than leaving recoverable passwords in the configuration file, though Site Manager still should not be treated like a dedicated password vault.
For me, its biggest benefit is reducing operator mistakes, not saving a few seconds of typing. Give entries unmistakable names such as “Client A staging” and “Client A production,” then assign the correct default local and remote directories. Site Manager can store the protocol, authentication method, directories, transfer settings, and other details for each connection. That matters when two servers have nearly identical folder layouts and uploading to the wrong one would be a bad afternoon.
I would set it up like this:
- Prefer SFTP or properly configured FTPS over plain FTP.
- Use SSH keys for SFTP when the server permits them.
- Protect saved passwords with a strong master password, or choose the option that never saves them.
- Use separate accounts with limited permissions instead of one all-powerful server login.
- Put “PRODUCTION” in the profile name if an accidental upload could affect a live site.
- Back up the entries, but assume an exported configuration may contain sensitive connection details.
I am less enthusiastic about keeping FileZilla’s active configuration in a cloud-mounted folder. CloudMounter may make remote storage appear local, but that does not automatically make an application’s live configuration safe to synchronize between two computers. Conflicting writes, stale copies, or accidentally shared credentials can turn a convenience feature into extra troubleshooting. A controlled export and import is less elegant, but often easier to understand and audit.
So yes, Site Manager is worth using even with only a few recurring servers. Just think of it as an organized connection launcher. The master password protects stored credentials at rest, while SFTP or FTPS protects the connection in transit. You need both concerns handled separately.
The hidden nuisance is that old profiles can quietly become wrong after a host, port, or folder changes, so give entries a quick cleanup when clients move servers. Otherwise, Site Manager is simply a reusable connection profile, and it is worth using once retyping details becomes more error-prone than maintaining them.
Create one Site Manager entry for a client you use regularly and connect with it a few times before moving everything over. Go to File > Site Manager, choose New Site, enter the protocol, host, port, login type, and username, then click Connect. You can leave the password unsaved if you prefer entering it each time.
The useful distinction is that Quickconnect is basically a temporary shortcut with history, while Site Manager is an actual connection profile. That history gets messy surprisingly fast when several servers have similar addresses or usernames. It also does not clearly tell you why an old connection was there. A named profile such as “Acme staging, SFTP” is much easier to recognize six months later.
Site Manager does not perform backups, synchronization, or automatic publishing. It only remembers how FileZilla should connect and, if configured, where to start on your computer and the server. You still need to check what you are transferring. I would avoid treating a successful connection as proof that you are in the correct web root, especially when hosts use folders with vague names like public, www, or htdocs.
There is another useful middle ground that gets overlooked: save the connection details but not the credential. That gives you most of the convenience without putting every client password behind FileZilla’s password storage. A password manager can handle the password, or you can use an SSH key where the hosting setup supports it. Master-password protection is available, as others mentioned, but you do not have to choose between saving everything and using Quickconnect forever.
Site Manager starts paying for itself when you have repeated connections, unusual ports, multiple accounts on the same host, or separate staging and live servers. If all you ever do is connect to one server twice a year, it is optional. For client work, though, clearly named profiles are usually less annoying than sorting through the Quickconnect dropdown and wondering which nearly identical entry is the right one.
Site Manager entries belong to that specific FileZilla installation and user account. They do not follow you to a new computer, so export them before replacing a machine or reinstalling the OS, and handle that export like a credential file.
Otherwise, yes, use it for recurring client work. Quickconnect is fine for disposable connections. Site Manager is better when you need a connection to remain identifiable six months later rather than becoming “that IP address I vaguely recognize.”
Everyone’s arguing about Site Manager security while ignoring that FileZilla also keeps a separate Quickconnect and recent-servers history, and that thing stores credentials in the same clear config format. So you can lock down Site Manager with a master password, feel safe, and still have half a dozen old passwords sitting in the recent list from when you were testing with Quickconnect. If you care about the plaintext issue at all, clear that history too. It’s under the Quickconnect dropdown, ‘Clear private data.’
@epicthinker4812 and @smartforge7235 are right that the plaintext-only claim is outdated, but I’d add a blunt caveat about the master password itself: there’s no recovery. Forget it and those saved credentials are gone, you re-enter everything by hand. On a machine only you touch, honestly I lean the same way @carl_node does. Save the host, port, protocol and username, skip the password, and let a real password manager or an SSH key handle the secret. That sidesteps the whole master-password-versus-plaintext debate instead of managing it.
On the cloud-sync idea, I’m with the skeptical take. CloudMounter is fine for what it does, making remote storage show up as a normal drive, and I get why it came up here. But FileZilla writes to its config while running, and pointing a live app at a synced folder is asking for conflicts or a stale copy overwriting good entries. Export, copy, import. Boring, but you always know which version is real.
The thing that bites people more than passwords is what @pixeladmin1772 mentioned. Stale profiles. A client migrates hosts, you connect out of habit to the old entry, it either fails or lands you somewhere unexpected. Name the folder path in the entry and glance at the remote directory after connecting instead of trusting a green ‘connected’ light. That single habit has saved more bad afternoons than any encryption setting.