// book 22
patriola.com

Book 22 · Patriola’s Guide to Claude

SSH to Your Web Host


Most deploys are unverified. The terminal says it finished, and you trust it. Then the live site serves the old file, or the transfer completed but the remote copy is one byte short and nobody notices for a week. This book fixes that at the script level.

Buy Kindle

Patriola's Guide to Claude — SSH to Your Web Host: Deploy, Verify, and Operate Sites Over SFTP
What this book is

A deploy pipeline that stops trusting and starts verifying

Every deploy that reports success and isn’t is built the same way: a transfer that completed, a script that exited 0, and no check that the remote file matches the local one. The SFTP transfer finished, but that only means the bytes arrived at the host. It doesn’t mean the file on disk matches what you uploaded. A partial write, a dropped connection mid-transfer, a host that silently truncated the file — paramiko returns success in all of these cases.

The patterns in this book come from five live production domains on DreamHost: real credentials, real directory layouts, real deploys. Every chapter draws from infrastructure that runs today. The sha256 verification block, the backup-before-mutate discipline, the php -l syntax check over SSH before a file goes live, the recursive directory walker that mirrors a local tree while skipping the directories that must never deploy — each one exists because the failure it prevents has already happened once.

What you’ll learn

Ten chapters from transport layer to deploy pipeline

  • the-paramiko-model — How paramiko’s Transport and SFTPClient relate to each other, when to use SSHClient instead, and the connection lifecycle that every subsequent chapter builds on. The difference between a transfer completing and a transfer succeeding.
  • backup-before-you-touch-anything — Downloading the current remote copy before mutating it, so there is always a rollback target on the server. The naming convention for backup files and how to clean them up after a successful deploy without losing the safety window.
  • upload-and-verify — Computing the sha256 hash of the local file, uploading via SFTPClient, then computing the hash of the remote copy over SSH. If the hashes match, the deploy succeeded. If they don’t, the deploy failed and the script stops.
  • running-remote-commands — Opening an SSH channel from the same paramiko session that holds the SFTP connection, running a command, capturing stdout and stderr, and checking the exit code. The pattern that lets a deploy script run php -l on the remote file before considering it live.
  • recursive-directory-deploy — Walking a local directory tree with os.walk, mirroring the structure to a remote path, and excluding directories that must never deploy. The logic for creating remote directories that don’t exist yet without touching the ones that do.
  • multiple-sites-one-script — A config pattern that stores credentials, remote roots, and file mappings for five domains in one place, isolated from each other, without duplicating the deploy logic. Switching from one site to another is one argument change.
  • a-reusable-deploy-helper — Extracting the connection, upload, verify, and remote-command patterns into a module that any script in the project can import. The interface that makes the helper composable without making it magic.
  • file-permissions-and-remote-fixes — Setting permissions on uploaded files over SFTP, diagnosing permission errors from remote command output, and fixing them from the deploy script without logging into the host manually.
  • credential-safety — Keeping host credentials out of version control while keeping scripts convenient to run. The .env pattern, paramiko’s key-based auth support, and what to audit before a script goes into a shared repository.
  • putting-it-together-a-deploy-pipeline — Chaining pre-flight check, backup, upload, verify, remote lint, permissions fix, and results summary into a single script that stops cold on any failure and exits nonzero so any upstream automation knows something went wrong.
From the book

A preview

The transfer completed but the remote file has the wrong hash. That is not a network error. That is a partial write, and paramiko returning success does not mean the file on disk matches what you sent.
You — after a deploy The transfer completed but the page is showing the old version.
Claude The SFTP transfer finished but that only means the bytes arrived at the host. It doesn’t mean the file on disk matches what you uploaded. Run the sha256 check against the remote copy. If it mismatches, the file got truncated or the connection dropped mid-transfer and paramiko still returned success. Re-upload and verify again before you trust the live site.
Volume is not the problem with deploys. Verification is. A pipeline that uploads a thousand files and checks none of them is a pipeline that can be wrong in a thousand places without telling you.
Who it’s for

Python developers who have been burned by a deploy that looked fine

The reader already knows Python, already has a web host, and has already been burned by a deploy that reported success and wasn’t. This is not a beginner tutorial on file transfer. It assumes knowledge of Python and basic SSH. It is the discipline layer that makes deploys verifiable and recoverable — sha256 verification, backup-before-mutate, and a pipeline that stops on the first failure.

The sister book SSH to the GPU covers compute offload to a remote machine. This book covers web hosting operations: SFTP, shared hosts, PHP files, and the five-domain multi-site pattern that runs real production traffic.

A longer excerpt is available to newsletter subscribers.

Buy Kindle

Stay current

New books in this series

One short email per book launch.