Workflows
Start from the job
Pick the situation. The guide linked from it has the steps.
- 01 First remote connection
- 02 Moving website files
- 03 Understanding SSH keys
- 04 Synchronizing directories
- 05 Automating repetitive transfers
First remote connection
You have a server account and need a remote directory to appear on your Windows PC.
Collect this first
- The protocol name the server actually accepts
- Hostname or IP address, which may differ from the public website
- Username, and the authentication method the administrator enabled
- The expected host key fingerprint when the protocol is SSH
Order of work
Confirm the protocol, open a session from the Login dialog, verify the server identity, and stop once the assigned directory is visible. Transfer files only after that listing looks right.
Watch for this
A website address is not always the file-transfer hostname. Accepting an unexpected host key just to get past the warning defeats the check.
Moving website files
A hosting account expects pages, styles, or images to be uploaded into a specific remote directory.
Collect this first
- The transfer protocol named in the host’s instructions
- The remote directory for the site, often different from the account home
- A local folder that contains only the files you mean to publish
Order of work
Connect, navigate to the documented web directory, and upload into that folder. Keep a copy of the previous file until the new one loads correctly in a browser.
Watch for this
Uploading to the home directory, or one level above the public folder, is the usual reason a site does not change after a transfer.
Understanding SSH keys
The server allows public-key authentication, or you want to stop typing a password for an SSH session.
Collect this first
- Permission to install a public key, or an administrator who will install it
- PuTTYgen, which the application can launch from the Authentication page
- A passphrase for the private key unless a carefully limited unattended job truly cannot prompt
Order of work
Generate a key pair on your PC, give only the public key to the server, and point Private key file at the PuTTY-format private key. Verify the host key separately. It is not the same key.
Watch for this
A private key file is a secret. It does not belong in email, a ticket, or a page on this site.
Synchronizing directories
A local folder and a remote folder should be compared, and only the differences should transfer.
Collect this first
- A protocol that preserves timestamps reliably. SFTP is the usual choice when it is available.
- A clear direction: update the remote copy, update the local copy, or both
- Preview left on before any option that deletes files
Order of work
Open Commands > Synchronize, choose the direction and mode, review the checklist of planned changes, and apply them only if every line is expected.
Watch for this
Mirror mode and delete options can remove files that are simply absent on the other side. SCP timestamp quirks also make poor comparison results.
Automating repetitive transfers
The same upload, download, or synchronization should run without clicking through the panels.
Collect this first
- A session that already works interactively
- A verified host-key fingerprint or TLS certificate fingerprint
- A script file encoded as UTF-8, with no real password written in it
Order of work
Test with the console, use -preview before a synchronize that could delete, then schedule winscp.com only after the log shows the paths you expect.
Watch for this
Batch mode does not ask before replacing files. A script that worked against a test folder can damage a live folder if the remote path is wrong.
If none of these match
A protocol question belongs in the comparison. A message you already see belongs in the error finder. A session you understand but want written out belongs in the connection builder.