What’s changed?

• Improved accessibility (WCAG 2.2 AA) and usability (UX) of the WebClient! UI with a small set of targeted optimizations

• Added an all-new CtxRelTargetPath() to our scripting engine, specifically designed to retrieve the destination (target) relative-path inside of the AfterFileRename event-handler

• Backups taken from nodes that used to be part of an HA cluster and then they left and went back to being stand-alone single servers now no longer contain legacy HA node bindings

• Usual small set of little bug-fixes and quality of life improvements

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

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

It’s available exclusively with the Ultimate license tier, and if you’re running one, it’s already there waiting for you.

What it is

Sixteen built-in operational reports, accessible directly from the Admin UI. Print them, download them, export them to JSON/CSV for further analysis, or just read them on screen. Every report is generated on demand from live data, so what you see reflects the actual state of your environment at the moment you run it.

The reports span several domains, including (but not limited to) operations, compliance, and security. And more will be added in future updates.

Why it matters more than it looks

Here’s the thing about enterprise file transfer environments: they accumulate. Users get created and forgotten. Permissions get granted and never revisited. Accounts that were set up for a partner integration three years ago are still sitting there, idle, with elevated access to production directories.

Nobody meant for that to happen. It just did, incrementally, across hundreds of small decisions that were each perfectly reasonable at the time.

Compliance audits and security reviews surface these problems, but only after the fact, and usually in the most stressful possible context. Enterprise Reporting gives you the visibility to catch them on your own schedule, before anyone asks.

Just two of the many possible examples that illustrate this well.

Inactive users shows every account that hasn’t logged in for 90 or more days, with a last-login timestamp and a total login count. That login count matters: an account with hundreds of historical logins that has gone silent for three months is a different conversation than a test account someone created and never used. Both are worth reviewing. Now you can see both at a glance, any time you want.

Elevated access shows which users have been granted permissions beyond the default, on which mount points, and against which Virtual File Systems. Delete directory. Delete files. Create symlinks. Each permission is listed individually per user, per path. If you’ve never run a report like this in your environment, the result may surprise you.

Not just for auditors

It’s tempting to think of compliance reporting as something you pull out when someone asks for it. A checkbox exercise.

The more useful mental model is operational hygiene. Inactive accounts expand your attack surface. Excessive permissions increase the blast radius of any compromised credential. Neither of these is a theoretical risk in environments moving sensitive business data over SFTP. Both are problems you can actually see and act on, now, without waiting for an external audit to tell you they exist.

That’s what this module is for.

All 16 reports, with more to come

The current release includes 16 built-in reports, here’s a list grouped by category.

Access & Identity

• VFS by user

• Users by VFS

• User inventory

• Authentication & MFS

• Inactive users

• Failed sign-ins

• Elevated access

Security & Compliance

• Blocklist

• Certificates & keys

• Security posture

• Shared objects

Storage

• Storage inventory

Activity

• User statistics

• Traffic & sessions

• Unused app-passwords

Automation

• Automation inventory

Future updates will add to that list. If there’s a specific report type that would be useful in your environment, reach out. We listen.

What’s changed?

• Adopted the new UI visual language that is now being implemented into all Syncplify software products to unify all UIs onto the company’s new official brand identity

• Also updated the Go compiler and standard library, which in turn includes the usual number of small bug-fixes here and there

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?

• Adopted the new UI visual language that is now being implemented into all Syncplify software products to unify all UIs onto the company’s new official brand identity

• A bug that prevented parametric VFSs (coming in from the Syncplify Server! side) from auto-creating their folder has been fixed

• Also updated the Go compiler and standard library, which in turn includes the usual number of small bug-fixes here and there

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 want to be upfront with you about what this release is, because it is not a typical point release.

V8.0.0 was a backend story: a rebuilt HA subsystem, containerization, OIDC, i18n, ACID transactions. Dense, foundational, deliberately non-glamorous. We shipped it, and we shipped it clean. What we held back, intentionally, was something that deserved its own release and its own announcement: a complete ground-up redesign of every user interface in the product.

What’s changed?

• All-new SuperAdmin UI. Not a refresh or a polish pass. A complete redesign, built from scratch with a clean design language, consistent information architecture, and a substantially reduced learning curve for new administrators.

• All-new Admin UI. Same philosophy. Every screen reconsidered, every workflow examined for friction and redesigned. If you have been using the Admin UI for years, expect to be surprised. In a good way.

• All-new WebClient! UI. Rebuilt from the ground up to be faster, cleaner, and immediately intuitive to end users who have never touched a file transfer product before.

• Accessibility as a first-class requirement. This is the main reason these UIs had to be rebuilt rather than revised. Our customer base has grown to include government entities and large regulated enterprises for whom accessibility compliance is not optional, it is legally mandated. Bolt-on accessibility does not work, and we refuse to ship it. The only path to genuine WCAG compliance was a clean start, so that is what we did.

• UX, reconsidered entirely. Five years of incremental additions had left our previous interfaces carrying debt we could no longer responsibly ignore. The new UIs are not just more accessible, they are more consistent, more predictable, and frankly more pleasant to use on an every-day basis.

• Mobile friendliness as a non-negotiable requirement. All of our UIs are now designed and optimized to be usable on (and auto-adapt to) desktop as well as mobile devices. We call this approach “desktop-first, mobile-excellent”.

• The usual collection of bug fixes, because no release ships without us having hunted down everything we could find.

Please make sure you read the upgrade instructions carefully. As always, you can download the most recent release from our website.

Here’s what’s new.

What’s changed?

• Containerization support. For the first time in Syncplify Server!’s history, you can run it in Docker, Kubernetes, Portainer, or any OCI-compatible container runtime. This has been one of the most requested capabilities over the years, and V8 delivers it properly.

• All-new High Availability subsystem. The HA architecture has been rewritten from the ground up. Performance and resilience are orders of magnitude ahead of any previous HA implementation, and for the first time the product ships with a full, genuinely elegant observability stack so you can actually see what your cluster is doing.

• OIDC support with app-passwords. Full OpenID Connect integration, with individual configurations per Virtual Site (SuperAdmin, Admin, and User tiers each have their own settings). App-passwords ensure that legacy protocol clients continue to work seamlessly alongside modern SSO flows.

• Internationalization (i18n). A genuinely large effort, and one we’re particularly proud of. V8 ships with full UI localization in English, German, French, Spanish, Italian, Chinese, Japanese, and Korean, with more languages on the way.

• Custom HTTP headers. You can now define custom HTTP response headers for the Admin UI, SuperAdmin UI, and WebClient! UI independently, giving you fine-grained control over security posture and compliance requirements.

• Backed by SyngoDB with true ACID transactions and compound indices. The underlying database engine has been significantly upgraded, bringing true multi-document ACID transactions and compound index support that underpins the reliability of everything built on top of it.

• Improved visuals and UX across all interfaces. Every UI in the product, Setup, SuperAdmin, Admin, and WebClient!, has received a meaningful refresh, particularly with regards to accessibility and user experience. The changes are evolutionary rather than disruptive, but the cumulative effect is noticeable.

• The usual collection of bug fixes, because no release ships without us having hunted down everything we could find.

Please make sure you read the upgrade instructions carefully. As always, you can download the most recent release from our website.

Thank you for trusting our software with your secure file transfers. V8 is something we’re genuinely proud of, and we hope you find it worth the wait.

What’s changed?

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

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?

• Updated the Go compiler and standard library to the most recent version, which comes with its own internal small bug fixes

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

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

Start with the question every security review eventually asks: where is the attack surface, and who owns it?

In the standard managed-file-transfer SaaS model, the answer is uncomfortable. Your files sit at-rest on the vendor’s infrastructure, and your endpoint is reachable because something inbound is exposed: a listening port, a NAT rule, a hole punched in the DMZ. You outsourced your file transfer and inherited two attack surfaces you don’t control: the vendor’s storage, and your own inbound exposure.

SFTP.cloud removes both. Not hardens. Removes.

The inverted data plane. Public clients (SFTP, FTPS, FTPES, HTTPS) connect to a highly available protocol edge in our cloud. That edge terminates the protocol and relays the bytes. It does not store them. A lightweight connector you deploy on or next to your own storage opens an outbound connection to that edge, and traffic flows back through it to where your files actually live: your subnet, your disks, your keys. The cloud sees an encrypted data stream. It never sees a file-system. NO CUSTOMER FILES HERE isn’t a policy we promise to honor, it’s a property of the design.

The two-fold inverted control plane. The same inversion applies to management. Your credentials, your access policies, your service configuration: none of it lives in our cloud either. Your control nodes connect outbound to the management layer; the management layer never reaches in. There is no inbound admin endpoint on your side to discover, scan, phish, or brute-force. There is no door to knock on.

Now add it all up the way a CTO has to:

• Inbound firewall rules required: zero. No NAT, no port forwarding, no DMZ. The connector dials out; nothing dials in.

• Customer files in the vendor cloud: zero. Your files stay in your storage subnet, under your control.

• Blast radius of a cloud-side compromise: a stateless protocol relay with no files and no standing inbound path to your network. Nothing to steal, and nowhere to pivot.

• Data residency: trivially answered, because the answer never changed. Your files never left your subnet.

We’ll say the rest plainly, because the category won’t: most “secure” cloud file transfer is really just secure storage of your files on someone else’s servers. We think that’s the wrong default. An attack surface you don’t have can’t be breached. And a file we never hold can’t be leaked.

For the record, SFTP.cloud remains an entirely new product, not a replacement for Syncplify Server!, R2FS!, or AFT!. It’s built for teams that need an internet-facing, fully managed endpoint without surrendering custody of their data to get one.

Release date is still under wraps. The connector deployment model, architecture deep-dives, and early-access details are coming. Subscribe, and we’ll post here first.

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!