Deployer Rsync
A deployer rsync workflow copies pre-built app files from your build runner to target servers. This method avoids running heavy build tasks or git clones on live hosts. Teams often set up this workflow with a single shared SSH key for the deploy user. When that role has broad permissions, one leaked key can expose the entire server. How a deployer rsync workflow operates In a standard git deploy, the live server pulls code and installs packages itself. That approach requires git, build tools,
Rsync: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A deployer rsync workflow copies pre-built app files from your build runner to target servers. This method avoids running heavy build tasks or git clones on live hosts. Teams often set up this workflow with a single shared SSH key for the deploy user. When that role has broad permissions, one leaked key can expose the entire server.
How a deployer rsync workflow operates
In a standard git deploy, the live server pulls code and installs packages itself. That approach requires git, build tools, and package tokens to live on the production host. A deployer rsync setup flips this model around.
First, your build runner checks out the code and compiles all assets in a clean workspace. It installs dependencies and runs tests before touching any live system. Once the build succeeds, the runner starts the transfer step.
The deploy tool opens an SSH session to each target server. It compares the local build folder against the remote release folder. Then it sends only the changed file blocks over the network.
On the remote host, the tool writes files into a fresh release directory. After the transfer finishes, the tool updates a symbolic link to point to the new folder. The web server then reads from the new release path right away.
What native SSH keys solve and what they miss
Native SSH keys verify that the build runner is allowed to log in as the deploy user. Linux file permissions also restrict which folders that deploy user can read or write. Together, these controls stop outside attackers from pushing files without a valid key.
Still, standard SSH keys leave a major operational gap open in practice. The host setup only checks who logs in at the start of the session. It does not inspect what individual commands or file transfers do in flight.
Rsync: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If an engineer copies the shared deploy key to a laptop, they can log in directly. From there, they can run extra shell commands or read sensitive app configs. Standard system logs only show that the shared deploy account logged in.
Those logs do not show which person or pipeline job triggered the run. Teams also struggle to rotate static SSH keys across dozens of servers and build pipelines. As a result, old keys stay active for months after team members leave.
Securing file transfers and remote commands
To reduce risk, teams should separate build steps from live host permissions. Start by removing build tools and source control keys from all production servers. Your live hosts only need the runtime packages required to serve the app.
Next, restrict the Linux deploy user so it only owns the web release directories. Do not grant full root permissions to the account that receives file transfers. If the deploy process must reload a service, allow only that single reload command.
Finally, replace shared static keys with identity-based controls that track each user and job. Every remote command should tie back to a verified person or pipeline run. Teams also need clear audit logs that record every command executed during a release.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why use rsync instead of pulling from git on the server?
Pulling from git requires repo keys and build tools on your live servers. Copying pre-built files keeps production hosts lean and removes source control keys from live machines.
How does the deploy tool avoid copying temporary or secret files?
You can define an ignore list in your deploy recipe before the transfer runs. The tool skips any local folders or secret files that match your ignore rules.
What permissions should the remote deploy user have on the host?
The remote user should only have read and write permissions inside the app release folder. It should never have broad root access to the rest of the operating system.