Connecting your own server (SSH/SFTP)

Add a machine on the Credentials page, under Servers, and it can be three things:

• •a drive — its folders open alongside your buckets, and you browse, upload, download, rename and delete exactly as you would in a bucket. Business plan.
• •a migration source — copy what is on it into a bucket, on a schedule, incrementally.
• •a migration or restore destination — pull a bucket down onto it. Business plan.

Adding and testing a server isn't plan-gated; using one as a drive or as a job endpoint is.

Linux and Windows are both supported, and BucketPilot works out which it's talking to rather than asking you — see How the platform is detected.

One address to allow through your firewall. Every connection BucketPilot makes — tests, jobs, browsing — comes from 3.111.107.194, so you can allow that single address on your SSH port instead of opening it to the internet.

The host key is pinned on first connect. If it ever changes, jobs stop and show you both fingerprints instead of connecting anyway — that's what an impersonated server looks like. Re-trust it from the Credentials page if the change was expected, such as a rebuild.

Now set the machine up. The steps differ enough by platform to be worth their own pages:

• •Setting up a Windows server → — OpenSSH is an optional feature that isn't installed by default, an administrator's key does not go where you'd expect, and Windows accepts some filenames it then stores somewhere else.
• •Setting up a Linux server → — usually already running, so it's mostly the key, the shell, and the session limits that decide how fast a job goes.

There's no operating-system dropdown, and there shouldn't be one: a wrong pick would silently apply the wrong path rules to your server. On the first successful connection BucketPilot asks the machine to resolve its own working directory. Windows answers with something like /C:/Users/Administrator; Linux answers /home/ubuntu. That answer is stored, and it decides how every path on that server is separated, compared and contained.

Two things follow:

• •A server that has never connected successfully hasn't been detected yet, and is treated as Linux until it has. Press Test Connection — a Windows machine then shows a Windows badge, and the test result says so.
• •Windows paths are written /C:/like/this throughout BucketPilot. That's the form Windows' own SSH server prints and accepts. You can type C:\like\this and it will be stored in the canonical form — so a path shown back to you with forward slashes is correct, not a display bug.

This one catches people on both platforms, so it lives here rather than on either setup page.

A drive rooted at / is the entire machine — the operating system, every installed program and every other user's files. BucketPilot will browse it, but it won't index it, so there's no search, no file-type or size breakdown, and no size alerts on it. The switch is shown and disabled, with the reason next to it.

On Windows a bare drive root — /C:/ — counts the same way, and that is the one that surprises people: it looks like an ordinary folder in a path box.

Root the drive at the folder you actually care about and index that: /srv/shares, /home/projects, /C:/inetpub/wwwroot, /D:/shares.

The test uses the same connection path a job does, so a test that passes means a job will connect too.

The failure stays on the server's card while you work through it, rather than disappearing after a few seconds.