Publish a large website instantly: rsync vs. FTP in WebAcappella Fusion

WebAcappella Fusion makes website creation accessible. The direct result: users get bolder. What was supposed to be a five-page showcase site turns into a 200-page portal, a blog built up over five years, or a store with 600 products. At first, it grows naturally. And then one day, publishing a page starts taking ten minutes. Then fifteen. Then twenty. And it’s not the site building that’s slow—it’s the transfer to the server.

Success that makes sites grow

The more accessible a tool is, the more it attracts ambitious projects. That’s exactly the story of WebAcappella Fusion: a city hall adding all its deliberations over five years (300 pages), a law firm publishing one document per decision (450 pages), a photographer creating one page per wedding (800 pages with galleries), a store ending up with 1,200 listings. These sites exist. They fit seamlessly into WA Fusion: multi-process construction generates them in a matter of seconds, even when they exceed 500 files.

But once the site is built, it still needs to be uploaded to the server. And that’s where things get complicated.

The moment when publishing becomes a nightmare

On a five-page site, FTP publishing is a breeze: three seconds, and it’s done. On a 500-page site with its images, CSS, JS, and product pages, the story changes. Here’s what users of large sites go through:

• A publish process that takes 15 to 30 minutes, during which you dare not touch the computer
• An 80% failure rate: the connection drops, the FTP client disconnects, and you have to start all over again
• Missing files: an interrupted transfer leaves part of the site in the old version, the other in the new
• Corrupted files: a poorly managed binary transfer, and the image appears broken online
• Constant uncertainty about what is actually online after a chaotic publication

This is not a fault of WebAcappella, your host, or your internet connection. It is a structural limitation of the protocol used.

FTP: a protocol from 1971

FTP, short for File Transfer Protocol, was specified in 1971. The context at the time: a few researchers were sending files between laboratories over ARPANET. Back then, transferring a hundred files at once wasn’t even a use case that had been considered. FTP was designed for simple transactions, not for the efficient synchronization of thousands of files.

Fifty years later, the protocol is still here, and so are its structural limitations:

• No incremental transfers within files: if a file has changed by a single byte, FTP resends the entire file
• One connection (or nearly one) per file: TCP handshakes accumulate file by file, which slows down sites with many small files
• No native integrity checking: FTP cannot determine if a file arrived identical to the original
• No automatic resumption: a network outage causes the transfer to start over from scratch (or leaves the system in an inconsistent state)
• Partial failure = broken site: if half the files transfer successfully and the other half fail, your site goes live in a mixed state that’s impossible to diagnose

On a five-page site, these limitations are invisible. On a 500-page site, they become crippling.

rsync: an algorithm designed for this

rsync, created in 1996 by Andrew Tridgell for his doctoral thesis, is not a transfer protocol: it is a differential synchronization algorithm. The difference is fundamental. Where FTP transfers, rsync compares and then transfers—only what has changed.

In practical terms, here’s what rsync does that FTP cannot:

• Intra-file delta encoding: if you modify two paragraphs in an HTML page, rsync sends only the modified blocks within the file—not the entire file
• A single multiplexed SSH connection: the entire transfer goes through a single secure channel, without renegotiation for each file
• On-the-fly compression: data is compressed before sending and decompressed upon arrival, drastically reducing network traffic
• Integrity checksum on every transferred file: no risk of corrupted files
• Automatic resumption in case of interruption: if the connection drops, rsync resumes exactly where it left off
• Coordinated deletion (option --delete): files deleted locally are also deleted on the server, preventing the accumulation of old ghost files

The result: on a 500-page site where you modify three paragraphs, FTP would potentially resend several entire files. rsync sends a few kilobytes and that’s it.

Natively integrated into WebAcappella Fusion

rsync is usually reserved for system administrators: command line, SSH key management, options to memorize. None of this is required of the WebAcappella Fusion user. The integration is seamless and invisible.

In your site’s publishing settings, rsync mode is available alongside FTP and SFTP. You enter your SSH credentials, and WA Fusion handles the rest: synchronization, compression, progress reports, and recovery in case of issues. You click “Publish,” and that’s it.

Our expertise in rsync doesn’t stop at WebAcappella Fusion. Intuisphere also develops and maintains RsyncBrowser, a standalone graphical SSH/rsync client for users who need to manage their syncs outside the site editor: server backups, data mirrors, script deployment, and one-off transfers of large volumes. It is in part this experience gained in the field that has allowed us to integrate rsync into WA Fusion with such finesse—SSH key management, clean recovery, clear progress reports.

Available from hosting providers with SSH access

rsync does not work over FTP: it requires SSH access on the server side. This requirement explains why not all hosting providers can offer it. Entry-level shared hosting plans are often limited to basic FTP, without SSH.

Web hosts that support SSH access (and therefore rsync in WebAcappella Fusion):

• o2switch: SSH enabled by default on all accounts — rsync works immediately, without any special configuration
• OVH: available on certain plans (Performance shared hosting, VPS, and dedicated hosting). Check your customer portal to confirm SSH access is available
• Linux hosting providers with SSH enabled: any provider offering shell access works (Infomaniak, PlanetHoster, and most VPS providers)

If your current plan only offers FTP, you have two options: keep publishing via FTP (which remains fully functional, though less efficient for large sites), or migrate to a plan that includes SSH if the size of your project warrants it.

The concrete benefit: your connection’s maximum speed

With rsync integrated into WebAcappella Fusion, the publishing throughput corresponds almost directly to the minimum between your internet connection’s upload speed and your hosting provider’s write capacity. There is no longer any protocol overhead slowing everything down.

In short:

• A one-time update (a few modified pages on a 500-page site) takes a few seconds — just enough time to send the changes
• A complete initial deployment of a large site takes exactly as long as it takes to transfer its files at your connection speed. No more
• No more timeouts, no more manual restarts, no more uncertainty about the site’s online status

Combined with the local multi-process architecture, the entire pipeline—from “I’ve modified content” to “the visitor sees the new version”—becomes nearly instantaneous, even on the largest sites.

Who is it for, and when?

If your site has just a few pages and FTP publishing takes ten seconds, you objectively don’t need rsync. Stick with what works.

If your project is growing, if you’re starting to avoid publishing because it takes too long, or if you’ve ever had a failed upload that left your site in a questionable state: that’s the sign. Check if your host offers SSH, switch to rsync mode in your publishing settings, and the difference is immediate.

This is typically the kind of feature you don’t realize you need… until the day you have it, and you wonder how you ever managed without it.