But here’s the honest truth we’ve been sitting with as we’ve grown: security is the floor, not the ceiling, of what “enterprise-grade” actually means.

Enterprise-grade means your platform works for your teams in Tokyo, your partners in Berlin, your clients in Milan, and your auditors in Seoul, all without forcing everyone to navigate a UI that was built for English speakers only. It means the software respects the user, not just the perimeter.

And that’s precisely why V8 will be the first truly multilingual version of our software. On day one of release, the UI will ship fully localized in eight languages:

🇺🇸 English
🇫🇷 French
🇩🇪 German
🇮🇹 Italian
🇪🇸 Spanish
🇨🇳 Chinese (Simplified)
🇯🇵 Japanese
🇰🇷 Korean

This isn’t a translation layer bolted on at the last minute. Internationalization (i18n) was built into V8’s architecture from the ground up, which means additional languages can be added in subsequent releases without touching core functionality. It also means that each user can override the server’s default language just for themselves based on their preference, without affecting other users.

More languages are already on the roadmap.

The security story hasn’t changed. The zero-CVE record, the zero-breach history, the architecture that Fortune 500 security teams trust, all of that carries forward into V8. What’s new is the recognition that the organizations deploying our software are global, and their users deserve a product that reflects that.

V8 is coming soon. Stay tuned.

Since then, several of you have asked what the backend of something like sftp.cloud actually runs on. Connector registration, session routing, access policy distribution, audit records, configuration replication across geographically dispersed nodes. That is a lot of operational state that must stay available, consistent, and survivable across node failures, regional outages, and network partitions.

SyngoDB is our embedded document database. It backs Syncplify Server!, R2FS!, and AFT!, handling configuration, metadata, and operational state reliably and fast. It supports optional RAFT-backed replication for multi-node deployment.

But sftp.cloud is a different beast.

RAFT is a CP system. Under a partition, the minority side stops accepting writes. In a single-datacenter cluster, that trade-off is entirely reasonable. But when your nodes are spread across multiple regions, “wait for a majority” imposes real write latency on a healthy cluster, and an isolated region stops accepting writes entirely until the partition heals.

That is not the operational model sftp.cloud requires.

Introducing GeoSyngoDB

GeoSyngoDB is the AP-first distributed document database that we designed and developed to power sftp.cloud.

AP-first is not a euphemism. Under the CAP theorem you cannot have Consistency, Availability, and Partition tolerance simultaneously. We deliberately chose Availability and Partition tolerance over global real-time Consistency. Reads and writes succeed on any healthy, reachable node even during a partition failure. The cluster converges to consistency once the partition heals. For sftp.cloud’s operational data model, that trade-off is correct.

Data is distributed across nodes using a token ring with no leader and no single coordinator. Writes go to a configurable number of replica nodes, selected from a topology-aware preference list that tracks each node’s datacenter, region, and VLAN, spreading replicas across failure domains before falling back to same-location nodes. When a replica is temporarily unreachable, its mutations are delivered once the node recovers. Background anti-entropy workers and passive read-repair keep replicas converging continuously after failures, re-partitioning, and topology changes. Membership is gossip-based: nodes discover and monitor each other without editing configuration files on every peer.

The icing on the cake? The local storage engine underneath all of this is still an embedded SyngoDB. GeoSyngoDB does not reinvent its document storage, indexing, or compaction. It delegates all of that to the same layer that backs our other products, keeping the physical storage layout clean and the I/O paths separate per namespace.

What it means for you as an sftp.cloud user

The infrastructure behind sftp.cloud’s control plane runs on a purpose-built, geographically distributed document store that we understand completely, because we wrote every line of it for this exact workload.

Session metadata, connector registry, access policies, and audit records live in a system that stays available through regional outages and network partitions, converges automatically after failures, and has no single point of failure anywhere in its data plane. No third-party SaaS database in the critical path. No opaque failure modes. No service agreement as a load-bearing architectural dependency.

sftp.cloud is not finished. But when it ships, the database layer underneath it will have been designed, built, tested, and benchmarked specifically for this workload.

Not borrowed. Not vibe-coded. Not bolted in. Built.

What’s changed?

• Fixed a small bug in the SftpClient object that was causing the DeleteSourceAfterDownload to fail in some specific circumstances.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

We’ve never liked with that model. So we’ve built an alternative.

sftp.cloud is a managed SFTP, FTPS, FTPES, and HTTPS file transfer service, with a web client and full secure file sharing capabilities. But its architecture works differently from everything else in this space, in a few ways that matter.

Your files are never stored in our cloud. Not during transfers, not at rest, not ever. The cloud component is a protocol relay, not a storage destination. You deploy a lightweight connector on or next to your own storage servers, it opens an outbound connection to the cloud, and from that point forward your on-premises storage has a fully managed, highly available SFTP endpoint on the internet, without a single inbound firewall rule required on your end.

No NAT. No port forwarding. No DMZ gymnastics. Just an outbound connection from your side, and a professional-grade file transfer service facing the world.

The control plane follows the same principle. Your sftp.cloud configuration, your user credentials, your access policies, and - above all - your files: none of it lives in our cloud. Your control nodes connect outbound to the management layer, not the other way around. There is no “doorbell” on your on-prem nodes for anyone to ring, because there is no door. Not a locked one. Not a hidden one. The attack surface simply does not exist.

We’re calling this an inverted control plane. It’s the first time this architecture has been applied to a cloud SFTP SaaS, and we think once you see how it works, you’ll find it difficult to settle for anything less.

One thing worth saying clearly: sftp.cloud is not a replacement for Syncplify Server!, R2FS!, or AFT!. Those products aren't going anywhere, and neither is our commitment to them. sftp.cloud is an entirely new product, built for a different set of use cases, specifically the organizations that need a managed, internet-facing file transfer endpoint without the overhead of running and maintaining their own server infrastructure, yet refuse to surrender control of their data to do it.

More detail on the architecture, the connector deployment model, and everything else is coming soon. If you want to be among the first to know when sftp.cloud opens for early access, subscribe to this blog. We’ll post here first.

What’s changed?

• Fixed a minor glitch (affecting only the Windows version) that sometimes prevented edits to the VFS permissions to be propagated back up to the upstream Syncplify Server! instance to which the VFS was connected.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed a two-tier bug that prevented offline license activation

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

SyngoDB is not a separate product you install, configure, and babysit. It is the embedded database layer used internally by Syncplify software products to store and retrieve configuration, metadata, operational state, and other product data that must be durable, consistent, and fast.

In other words, SyngoDB is one of those components you only notice if it fails. And it doesn’t.

That said, a lot of product behavior eventually depends on this hidden layer: searches, sorted views, paginated results, metadata scans, state lookups, configuration reads, index maintenance, and a long list of small operations that happen constantly while the visible product is doing its job.

So we recently completed a focused performance sprint on SyngoDB.

The goal was simple: make it faster and more memory-efficient where it matters, without compromising the things that matter more.

And yes, that second part is important.

Performance work in a database is not like performance work in a stateless utility function. You don’t get to “optimize” by casually skipping copies, weakening consistency, changing key formats, or introducing clever shortcuts that only work until the system is under load, recovering from a crash, or serving concurrent requests.

For this sprint, every change had to satisfy a strict set of rules:

• no public API changes

• no storage format changes

• no weakening of ACID behavior

• no changes to RAFT boundaries

• no speculative caching with unbounded memory growth

• no benchmark-only tricks

• no “fast, but only if nobody looks too closely” code

Every accepted change needed correctness tests, before-and-after benchmarks, and a full verification pass.

The biggest improvements came from query execution paths.

We improved those paths by making the query planner and execution code more careful about when it can stream from indices, when it can stop early, and when it can safely reuse already-decoded documents within a single query execution.

A few representative results from our internal benchmarks:

That is roughly a 58x improvement on that benchmarked path!

That is about 20% faster (and with fewer memory allocations).

That is roughly 18% faster on the measured path.

We also tightened lower-level bounded index scans so that limits are honored earlier instead of scanning more data than needed and trimming later. That matters because “give me the first 20 matching results” should not behave internally like “find far more than 20 things and then throw most of them away”.

The engine layer also received careful improvements, mostly around iteration and read paths. These were deliberately conservative.

Where public APIs require stable byte slices, SyngoDB still returns stable byte slices. Where internal code can safely avoid extra value work and only needs keys, it now does so more efficiently.

That is the kind of performance work we like: measurable, boring in the right places, and not something that would turn into a future support ticket.

So what does this mean for Syncplify products?

It means the internal database layer behind them is now faster in several important areas, especially around searches, sorting, pagination, indexed lookups, metadata access, and internal scans.

It does not require customers to migrate anything. It does not require a configuration change. It does not alter the reliability model. It simply makes a core internal component better.

That is often the best kind of infrastructure improvement: not loud, not flashy, not something that requires a new checkbox in the UI, but something that improves the behavior of everything built on top of it.

SyngoDB remains the quiet database layer behind all Syncplify software. Now it is quieter, because it spends less time (less CPU, and less RAM) doing the same work.

What’s changed?

• Fixed a bug that prevented the deletion of secrets by name both via UI and REST API

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

That position was never arbitrary. It was a direct consequence of what SSO meant in practice for most of that time: SAML.

SAML is old. It was designed in an era when XML was considered elegant, and when “federated identity” was a concept so new that nobody had yet discovered all the ways it could go wrong. The CVE history of SAML implementations across the industry is not a pretty read. XML signature wrapping attacks. Assertion forgery. Parser differentials that let maliciously crafted tokens slip past validation. Every major SAML library has been burned by at least one of these, and many have been burned repeatedly.

Syncplify Server! has exactly zero CVE entries in the NIST National Vulnerability Database since its inception in 2013. That’s not a statistic we stumbled into. It’s the result of deliberate, sometimes uncomfortable decisions about what we will and will not put into the product. Adding a SAML stack would have meant inheriting its entire attack surface. That was a trade-off we were not willing to make, and we said so (sometimes too openly) every time the subject came up.

So what changed?

OIDC happened. And more importantly, OIDC matured.

OpenID Connect (OIDC) is not “SAML but newer.” It’s a fundamentally different approach to the same problem. It’s built on OAuth 2.0, it uses JSON Web Tokens instead of XML, it’s thin by design, and its security model is dramatically easier to implement correctly. The attack surface is smaller, the specifications are cleaner, and the ecosystem has had enough time to find and fix its edge cases. OIDC is what SSO looks like when you design it with modern threat models in mind rather than retrofitting security onto an XML messaging framework from 2002.

The protocol finally earned a place in Syncplify Server!. That’s the whole story.

What’s coming in the next major version is full enterprise-grade OIDC support: federated login into the SuperAdmin, Admin, and WebClient! UIs, and (importantly) app-passwords for legacy clients like FileZilla and WinSCP that don’t speak OIDC natively but still need to connect via SFTP/FTPS. The app-password model keeps the security benefits of your Identity Provider (IdP) in place while not leaving older tooling behind. We think it’s the right balance.

More details when the release is ready. In the meantime, if you missed the teaser, here it is.

Here’s a few screenshots for you:

What’s changed?

• Upgraded the embedded back-end database to SyngoDB v6.3.0 (which features better atomicity and faster document-locking mechanism)

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• More accurate and faster reconciliation of VFS configurations when the remote Syncplify Server! node(s) configuration is edited

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Syncplify Server! has a built-in protection mechanism, called Protector!, that automatically block-lists IP addresses exhibiting suspicious behavior. It works brilliantly against actual attacks. Against your own load balancer, though, it will work just as well, and that is the problem. If your load balancer’s IP address is not in the safe-list, Protector! will eventually block it, and when that happens, every node behind that load balancer stops accepting connections. Not because the software failed. Because it did exactly what it was told.

The fix is a single configuration step: every IP address used by every load balancer in your HA deployment must go in the safe-list. Not the allow-list (which has entirely different semantics), not the block-list (obviously), the safe-list. Safe-listed addresses are never auto-blocked, regardless of how many times they connect and disconnect without authenticating. This is precisely what the safe-list was designed for. Full details on all three list types are in our knowledge base, alongside the complete HA setup guide. If you are running a load-balanced HA cluster and have not checked this, now is a good time.

Containerizing a product like Syncplify Server! is not trivial. The server runs three cooperating processes: the SyngoDB database engine, the REST API and control plane, and one worker process per virtual site. These processes communicate over loopback addresses, which do not cross container network boundaries. Rather than rewiring the IPC layer entirely, we chose a monolith container model: all three processes share a single network namespace inside one container. Every loopback address works identically to bare metal, and IPC code didn’t need to be altered.

The bigger challenge was the worker lifecycle. On Linux, virtual site workers have always been managed by systemd. Inside a container there is no systemd. We built a small in-process supervisor that replaces systemd in container mode: it forks, monitors, and terminates worker processes directly, with graceful SIGTERM handling and a even a kill-timeout that mimics bare metal and VM operation. The switch is activated by a single environment variable.

The container image is built for both linux/amd64 and linux/arm64 and published as a multi-arch manifest on Docker Hub. Deployment is a single docker compose up -d. The data directory, log directory, and user “homes” are mounted from the host, so the license, configuration, and all virtual site data persist across container restarts and image updates.

It even support hybrid clustering, with some nodes running in bare-metal/VMs, and some other nodes running in/as containers!

We are in the final testing phase. The Docker image and a full deployment guide will ship soon with one of the upcoming release. Stay tuned.

When Syncplify Server! v7.5 is released (please, be patient just another little bit!!) it will come with an additional deployment option on top of the usual “download and install”: a docker container image.

Stay tuned for more…

What’s changed?

• Upgraded back-end SyngoDB server to version 6.2.3

• Fixed several accessibilty issues in the WebClient! UI

• Fixed a few minor bugs to all 4 UIs (Setup, SuperAdmin, Admin, and WebClient!)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Meet grinder, our in-house multi-protocol stress testing utility. It doesn’t just push data at a server as fast as the network allows. It simulates the worst real-world conditions imaginable: connection drops, jitter, backoff cycles, the full chaos of a production environment having a very bad day. Two instances, each hammering a different node of the same cluster simultaneously, with 10 concurrent connections each and a 50MB buffer per session.

In short: grinder is every SFTP server’s nightmare. And we pointed two of them at a two-node Syncplify Server! v7.5.0 HA cluster running our brand-new clustering subsystem.

The result? Completely smooth. Rock stable. Not a single crack.

Node one held at 426 MiB/s. Node two at 341 MiB/s. Combined throughput north of 750 MiB/s (that’s mebibytes per second, not megabits!) sustained across both nodes simultaneously, under full grinder conditions, while the HA subsystem handled synchronization in the background without breaking a sweat.

The dashboard tells the story clearly: 30-40 concurrent active sessions across both nodes, uploads and downloads running in parallel, data transfer peaking near 1,000 MiB/s on individual bursts. Zero rejected sessions. Zero instability.

This is the same new HA algorithm we teased recently, the one we rebuilt from scratch to handle time drift, fast catch-up after node inactivity, and per-node per-site draining with full observability. Under grinder load, it performed exactly as designed.

We’ll have more to share soon, including the full release details. But if you run Syncplify Server! in a high-availability deployment you’ll definitely want to deploy this new version when it becomes available.

Syncplify Server! v6.x has been retired and is under Limited Long-Term Support (LLTS). Under normal circumstances, no new v6 builds would be produced. This release is an exception, made exclusively because a critical defect affecting some but not all HA (high-availability) clusters warranted a backport.

What’s in this release

• Critical fix (backported from v7): Corrected an HA node communication defect that could (in some limited cases) cause cluster nodes to exchange excessive inter-node traffic, consuming significant network bandwidth while performing no useful work. In severe cases this could degrade the cluster performance.

That’s it. There are no new features, no other fixes, and no roadmap changes. This is a surgical release for one reason only.

A reminder about v6 support status

Version 6 is retired. LLTS means we address critical defects when the impact is severe enough to justify it. It does not mean v6 is back on the active development track, and it does not mean future issues will always receive backports.

If you are running v6, the right long-term answer remains the same: upgrade to v7. It is more secure, more capable, and actively maintained. Every day on v6 is a day without the improvements, protections, and fixes that ship continuously in v7.

If you are running an HA cluster on v6 and cannot upgrade immediately, apply this release. Then make upgrading to v7 your next scheduled priority.

You can download the most recent releases from our website.

Thank you for your continued trust in Syncplify.

The first generation of Syncplify Server!’s HA subsystem was built incrementally, as the product grew and as customer deployments grew more ambitious. It worked. But four years of production data, support cases, and internal tooling gave us a precise catalog of the edge cases it handled imperfectly and the operational experiences that were harder than they needed to be. Rather than continue grafting improvements onto a design which foundational assumptions were no longer sound, we made the decision to rewrite the entire HA subsystem from scratch.

This is not a reversal. It’s engineering maturity. Here’s what changes.

Automatic Recovery From Node Failures

When a node goes offline, the current implementation keeps it marked offline until the cluster is explicitly told to reset it. A transient hiccup, something that resolved itself in 30 seconds, can still require administrative intervention to clear.

The new engine recovers automatically. When an offline node comes back, the cluster detects it, catches it up on any missed changes, and resumes normal operation. No manual steps, no scheduled tasks to babysit.

For most customers on stable infrastructure, this will never matter. For customers running in cloud environments with occasional transient connectivity events, it matters every week.

A Dedicated Heartbeat, Separate From Data Sync

The existing subsystem infers node health from whether data synchronization succeeds. If a node has nothing new to sync, there is no communication at all, and silence is indistinguishable from unavailability.

The new engine introduces a lightweight, continuous heartbeat that runs independently of data replication. The cluster always has an accurate, current picture of which nodes are reachable, regardless of whether any data has changed recently.

Continuous Clock Verification

All timestamp-based HA implementations require synchronized clocks. The new engine goes further: it continuously verifies clock accuracy continuously during operation, not just at startup, and it can detect when a specific node is the one drifting, rather than only detecting that a difference exists. A node that determines it is the source of drift can self-quarantine from pushing changes, preventing incorrect data from propagating.

Stronger Inter-Node Authentication

Every inter-node request in the new design is cryptographically signed, covering the full request body. A timestamp embedded in every signature prevents replay attacks. Combined with TLS transport, this closes a class of inter-node threat scenarios that the previous implementation did not fully address.

A Wire Format That Survives Rolling Upgrades

The previous implementation used a binary encoding that fails silently when the data structures on two nodes diverge, as they inevitably do during an upgrade. The new design uses a versioned, human-readable wire format. Unknown fields are ignored gracefully. Protocol version mismatches are detected and reported cleanly rather than causing silent data corruption.

Automatic Tombstone Purging

Deletion records used to accumulate indefinitely, requiring manual cleanup. The new engine purges them automatically on a configurable schedule. A node that has been offline long enough to miss the purge window is handled gracefully on reconnection, with no operator involvement required.

The Worker Is Simpler

In the current design, the worker process participates in HA replication with its own sync cycle and its own database connections for that purpose. In the new design, replication is an exclusive responsibility of the ss-webrest process. The worker is notified of relevant changes via IPC and reloads only what changed. Its behavior is identical whether HA is enabled or not.

What Does Not Change

The behavioral contract is preserved. Two-node active-active HA, the same replicated collections, the same operational model. The upgrade path from the current implementation will be clear and documented.

We will publish more detail, including the migration procedure for existing clusters, closer to the release date. If your deployment has specific edge cases you want to make sure we have covered, or if you’re interested in BETA-TESTING this new HA approach, please reach out to us directly via https://syngo.to/support.

Not a cosmetic refresh. A complete overhaul of the synchronization algorithm, with meaningful gains in speed and resource efficiency, plus first-class handling of edge cases that were simply not on the radar before: time drift, fast catch-up after extended node inactivity, and elegant per-node, per-site draining with full observability.

Speaking of observability, here’s a sneak peek at where things are headed:

No release date to announce yet. But if HA deployments matter to your infrastructure, this one is worth keeping an eye on.