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.

What’s changed?

• Vastly improved the VFS Configuration section in the Admin UI, its user experience (UX) is now much cleaner and user-friendly

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 one critical bug that could cause mis-mapping of the REST API port for inter-node communication and synchronization between HA (high-availability) nodes belonging to the same set

• Made setting permissions onto shared objects (files and folders) in WebClient! much clearer and easy to understand

• Several other “quality of life” improvements to WebClient!, including but not limited to, a convenient “refresh” button, a more consistent editing experience for “self” (own profile), the ability to set custom colors (light and dark) for WebClient!’s title and disclaimer, and a few other accessibility improvements

• Block-list items are now included in backup/restore operations (NEW!)

• OTP inputs on all 3 UIs are now auto-focused if/when they appear

• Vastly improved SMTP configuration and testing

• Several more small bug-fixes to all 3 UIs (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!

Here is what changed, and why it matters.

The SyncJS library is now the common cross-product engine. Previous versions of AFT! had their own bespoke (and somewhat incompatible) SyncJS implementation. Starting with v4.0, every AFT! automation uses the new SyncJS engine shared library: the same engine that powers Syncplify Server! event handlers and R2FS! storage backend scripting tasks.

This is not a compatibility layer; it is a true unification. A script you write for AFT! will run on Syncplify Server! without modification (except for APIs that are product-specific by design), and vice versa. One scripting language. One API surface to learn. One VSCode extension to install.

Speaking of which: the SyncJS VSCode extension is already AFT!-aware. Install it, set syncjs.product to aft (which is the default), and you get full IntelliSense for every SyncJS built-in, every AFT!-specific extension (FsWatcher, RemoteWatcher, WaitForHaltSignal, Params, JobID), and the full SyncJS API surface. The extension also bundles MCP servers, so AI coding assistants like GitHub Copilot (etc) have accurate, real-time awareness of the AFT! scripting API.

Scripts can run long-lived jobs or one-shot executions. This is the design choice that opens the most doors. An AFT! script can run as a persistent process. WaitForHaltSignal() blocks the script until an operator stops it via the web UI or the REST API, which means scripts can react to events in real time rather than polling on a schedule. FsWatcher monitors local directories for file-system events (create, write, remove, rename, chmod) and fires a callback the moment something changes. RemoteWatcher does the same for remote directories. Both support recursive subdirectory tracking. Newly created subdirectories are covered automatically, with no extra logic required. Scheduled execution via a cron-compatible built-in scheduler is still fully supported for batch workloads. The two models coexist.

The VFS Library replaces hardcoded credentials. Connection profiles (SFTP, FTP/S, S3, Azure Blob, GCS, local filesystem) are defined once in the VFS Library with a name and tested independently. Scripts reference them by name using VirtualFSByName(). Credentials never appear in script code, and the same script works across environments by simply changing which named profile it references. This is the AFT! equivalent of the VFS Library concept that Syncplify Server! users already know well.

CopyToVFS/MoveToVFS transfer without touching local disk. When copying or moving a file from an SFTP server to an S3 bucket, AFT! streams it directly between the two endpoints. Nothing is staged locally. And if it’s a “move” operation, the source file is removed automatically after a successful transfer.

Named Secrets keep credentials out of scripts. Passwords, API keys, and other sensitive values are stored encrypted in AFT!’s secrets store and retrieved at runtime with GetSecret("secret-name"). They never appear in plain-text anywhere in the script.

The full SyncJS function library is available. That means SFTP, FTP/S, S3, Azure, and GCS client objects with a uniform upload/download API; fluent HTTP client for REST API calls; SQL database access; AMQP messaging (RabbitMQ and Azure Service Bus); PGP encryption and signing; HMAC signing and verification; CSV and XML parsing; email, Slack, Teams, Telegram, and Twilio notifications; process execution with output capture; encoding and compression; image processing; and TcpConnect for lightweight health checks. The 21 new SyncJS core functions announced last week are all available in AFT! v4 as well.

The admin UI has been completely redesigned and vastly improved. New dashboard, new script editor with syntax checking, cron job management, op log, license management, and settings, all rebuilt. Login is now protected by bcrypt-hashed passwords and TOTP-based two-factor authentication.

Migration from AFT! v3 is a single command. Run aft import-from-aft3 and your existing v3 JavaScript scripts are imported. They will require review, and likely some adaptation to the SyncJS API, but the import step eliminates the manual copy-paste work.

It ships as a single binary with no external dependencies. One file. No runtime, no sidecar processes. Drop it on Linux or Windows, run it interactively, or install it as a system service with one of the supplied installers, and it is operational. The binary is CGO-free and statically linked.

Come check out the new AFT! at syncplify.com!

What’s changed?

• Fixed a minor issue in the installer (not the software itself) that wasn’t able to correctly identify updates/upgrades for fully-licensed instances.

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

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