Files: FTP, SSH, and where things live

Your website is, in the end, a directory of files on a server. This guide covers where that directory is, how to get files into it (SFTP and FTP), what SSH access means on our plans, and the one limit people forget exists until they hit it: the file count.

Where your files live

Every account runs in its own isolated container with its own filesystem — your files sit next to nobody else’s. Inside your account, the directory the web server actually serves is public_html. A few practical consequences:

• A file at public_html/photo.jpg is reachable at yourdomain.com/photo.jpg.
• Files outside public_html (scripts, config, exports) exist in your account but aren’t served to the web — a useful place for things visitors shouldn’t fetch.
• Paths in cron jobs and scripts can reference it as ~/public_html/….

When you create an FTP account and leave its home directory blank, it lands at your website root. You can also scope an account deeper — more on that below.

FTP accounts: create, scope, delete

You manage FTP accounts from the portal — log in at my.candorhost.com, open your hosting service, and choose the FTP Accounts tab. To create one:

1. Enter an account name. The full username becomes name@yourdomain.com — the domain part is part of the username, not just decoration, so use the whole thing when you connect.
2. Set a password.
3. Optionally set a home directory, relative to your website’s base — for example public_html/uploads. Leave it blank and the account starts at your website root.

The tab shows your existing accounts with each one’s home directory, and a Delete button next to each. Two things worth knowing:

• Scoped accounts are the point. If a contractor only needs to update images, give them an account homed at public_html/uploads — they can’t wander anywhere else. One task, one account, delete it when the job’s done.
• To change an account’s password, delete the account and create it again with the same name and a new password — the tab supports create and delete, not edit.

The connection details are printed right on the tab, but for reference: the host is your own domain, SFTP uses port 22 (recommended), plain FTP uses port 21, and the username is the full name@yourdomain.com.

How many FTP accounts do you get?

The exact numbers, same as everywhere else on this site:

	Solo	Studio	Org
FTP accounts	2	10	30

The Usage & Resources tab on your service shows how many you’re using against your limit.

SFTP or FTP? SFTP.

Same credentials, same host — the difference is that SFTP (port 22) encrypts everything in transit, while plain FTP (port 21) sends your password and files in the clear. Every mainstream client (FileZilla, Cyberduck, Transmit, WinSCP) speaks SFTP; pick it in the protocol dropdown and you’re done. Port 21 exists for old tooling that can’t do better; if you have a choice, and you almost always do, use SFTP.

Either way, every login surface — FTP, SSH, mail, web — sits behind brute-force protection, so repeated failed logins can temporarily lock you out. If you fat-finger your password many times in a row and suddenly can’t connect at all, that’s probably what happened; tell us and we’ll sort it out.

SSH access

SSH is included on every plan — it’s not an upsell tier. It gives you a real shell in your own container: unpack an archive server-side instead of uploading 40,000 files one at a time, tail a log, move things around at the command line. An SSH password is set for your account when it’s provisioned.

The honest gap: this page doesn’t print the exact SSH hostname and username because they’re account-specific. If you don’t have them handy, ask us — a straight question gets a straight answer, and we’ll get you connected.

Inode limits — what “too many files” means

Storage limits get all the attention, but there’s a second quota: inodes, which is effectively the count of files and directories in your account. Every file, folder, and symlink uses one.

	Solo	Studio	Org
Inodes (files)	250,000	500,000	500,000

Why it matters: when you hit the inode cap, creating new files fails — even if you have gigabytes of storage free. Uploads error out, caches can’t write, updates half-complete. It looks like a mysterious breakage until you know what it is.

In practice the limits are roomy — a typical WordPress site is tens of thousands of files, not hundreds of thousands. The usual culprits when someone does hit the cap:

• Cache directories that were never pruned (session files, page caches, thumbnail regenerations)
• Old backup archives unpacked inside the account — restore what you need, then delete the extracted tree (your real backups live on separate infrastructure and don’t count against you)
• node_modules — build locally, upload the built output

If you’re near the limit and can’t see why, open a ticket and we’ll help you find where the files are hiding.

Related

• Getting started — first steps after signup
• Backups — automatic, included, restore yourself
• Cron jobs — scheduled tasks that run in your account
• PHP versions and limits — the other limits, also published