On this page
Hello everyone, and welcome to the April and May 2026 Filen status update.
It has been a little longer than usual since our last update, so we decided to combine April and May into one post again. Not because nothing happened, but because much of the work during this phase happened below the surface.
Over the past weeks, we made important progress across several areas: the mobile app migration, the new Rust SDK, the sync engine rewrite, infrastructure work, support tooling, marketing preparation, security process updates, and many smaller operational improvements that do not always fit neatly into one public headline.
We know phases like this can sometimes look quiet from the outside. Internally, they are anything but quiet. Much of our current work is about making Filen more stable, faster, easier to maintain, and better prepared for the next major platform steps.
We still plan to return to a more regular monthly rhythm soon. For now, this combined update felt like the best way to give you a proper overview without splitting closely connected topics across separate posts.
So, let us get started.
Mobile app Rust migration and internal beta
Let us start with one of the most important development milestones: the new mobile app, built on top of the Rust SDK, is now ready for internal testing.
The mobile app was one of the most complex migration targets, and getting it to this point took a lot of detailed work. The goal was not just to rebuild the same app with a different technical foundation. The goal was to move one of our core products onto the new shared Rust base, while improving performance, stability, predictable behavior, and long-term maintainability at the same time.
A large part of the work was about reaching feature parity with the existing app while using the migration as an opportunity to clean up and improve many smaller flows along the way. This touched almost every part of the app, from file handling and sharing to media previews, offline behavior, chats, settings, authentication, and general navigation. Most of these changes are not meant to feel like new features, but together they should make the app feel more polished, consistent, and reliable in daily use.
There were also a lot of targeted improvements that came out of the migration work itself. Some examples include better permission handling, improved sort options across drive screens, cleaner empty screens, better context menus, improved preview behavior, more efficient thumbnail generation, better handling of offline files, improved upload and download handling, and various Android-specific improvements around background transfers.
Media handling also received a lot of attention. The new app includes improvements to photo browsing, including date ranges while scrolling and adjustable grid density, improved image and video previews, audio playback, better playlist handling, and better behavior around large audio files or device rotation during previews. These are the kinds of details that do not always sound huge on their own, but together they make the app feel much more polished.
Another important part is reliability around edge cases. We worked through many smaller issues around public linked folders, importing linked files or folders, files not being previewable immediately after upload, password-protected PDFs, offline cleanup on logout, storage limit prompts, biometric authentication behavior, privacy screen behavior, and other cases that can create frustration when they do not behave as expected.
Global Search is also part of the new Rust SDK foundation, but it is worth adding a bit more context here because the implementation changed quite a lot. The new search system is built on top of the new caching system and is designed to work with the files and folders already in your drive. That means users should not need to reupload files just so they can appear in search.
This is important because we often received feedback from users who didn't quite understand why some files showed up in Global Search and others didn't. Search should feel like a natural part of the drive, not like a separate feature that only works for certain files or only after new uploads. The new caching system makes that possible by giving the clients a more reliable local foundation to work with. That cache is generally complete for the current search work and is already being used by the new Global Search implementation, although it may still need some additional adjustments as the sync engine rewrite progresses.
Global Search will become available across products as they move to the new Rust SDK. For now, it is still somewhat limited because there are internal product and planning questions we want to resolve before treating it as fully finished everywhere. But technically, the foundation is now there, and that is a meaningful step.
The new app will now go through internal testing first. If that goes well, we will move into a community beta and share more details when that step is ready. The exact timing can still change depending on what we find during internal testing, but the project is now clearly moving from migration work into real testing.
The new app should feel faster and smoother in everyday use. More importantly, it should also be easier for us to maintain and improve going forward. A lot of mobile issues are not caused by one obvious bug, but by complicated interactions between local state, sync behavior, file handling, caching, permissions, and platform-specific edge cases. Moving more of that logic into the Rust SDK gives us a cleaner and more consistent foundation to build on.
And as mentioned before, this is not the end of the Rust migration. Once the mobile beta is running and the results look good, the next major migration targets are the web app and the desktop client.
Why the Rust SDK matters
A lot of our updates over the past months mentioned the Rust SDK, so it is worth repeating why this work matters so much.
The TypeScript SDK has been the shared foundation of Filen's clients for a long time and served that role well. The Rust SDK is the next step in that evolution: a faster, stricter, and more robust technical base for the same core responsibility.
This matters because many of Filen's most important operations happen on the client side, or very close to it. Encryption, metadata handling, file operations, caching, previews, search, and sync-related logic all need to work reliably across different platforms. Moving this foundation to Rust gives us better performance characteristics, stronger tooling, clearer boundaries, and a more reliable base for testing, debugging, and future features.
Users should notice this over time through better performance, fewer edge-case issues, and more consistent behavior across products. It also prepares the ground for the larger roadmap ahead, including Global Search, the sync engine rewrite, API v4, and Filen Spaces.
We still sometimes describe the SDK as being around 99% complete, even though it is complete enough for the current phase. That is intentional. In software development, something like this is rarely "done" in an absolute sense. As more products migrate to the SDK, we will almost certainly find smaller follow-up tasks, edge cases, and improvements that need to feed back into it. But for practical purposes, the SDK is now mature enough that the new mobile app can be tested on it and the next migration steps can move forward.
What comes after the new mobile app
Once the mobile app reaches the community beta stage and the test results look good, the next major migration targets are the web app and the desktop client.
The good news is that these migrations should be faster than the mobile migration. The mobile app did a lot of the heavy lifting. It forced us to solve many of the difficult SDK integration questions first, and that work should make the next clients easier to migrate.
The goal is still that all Filen clients eventually run on the Rust SDK. Once that is done, the legacy TypeScript SDK should no longer be needed for core client logic. That is an important milestone because it reduces fragmentation and makes it easier for us to build future features on one shared technical base.
After the main product migrations, we also want to spend time on internal tools and marketing-related systems. One example is bringing back and improving our promo code tooling, which is important for marketing campaigns and creator partnerships. Another is improving internal dashboards for employees, so our support team can investigate, understand and resolve issues faster.
These tools may not be very visible from the outside, but they make a real difference internally. Good support tools can make a real difference in how quickly we can help users.
We cannot give an ETA for all of this yet. The migrations still need time, and internal tools need to be built carefully. But the direction is clear: finish the SDK migrations, improve the internal systems around them, and then move into the next major platform phase.
API v4, Filen Spaces, and the bigger picture
All of this groundwork also connects back to the larger roadmap we have already talked about in previous updates: API v4 and Filen Spaces.
We will not repeat the full explanation here, but as a reminder, the short version is that API v4 is planned as a larger rebuild of how Filen clients communicate with the service, moving toward WebSocket-based communication instead of relying on the current request-heavy model. The goal is a faster and more responsive experience, fewer unnecessary round trips, better state handling, and a technical foundation that makes future features easier to build.
Filen Spaces builds on that foundation. The idea is to rethink file sharing around shared virtual spaces where groups can work with and access data together more naturally. In the long run, this is also the direction that enables more advanced team, business, and collaboration features.
For now, the important point is that the current Rust SDK work, the client migrations, the new caching system, Global Search, and the sync engine rewrite are not isolated projects. They are all part of preparing Filen for that next platform phase. We are also still evaluating whether parts of the API v4 and Spaces work could be supported through cooperation with local research institutions or regional funding programs.
So while there is no new major API v4 or Spaces announcement in this update, the direction has not changed. The work happening now is what makes those next steps possible.
Sync engine rewrite
In parallel to the client migration work, the sync engine rewrite is also starting now.
This is a separate project, but it is closely connected to the Rust SDK work. Until now, the team working on the new mobile app and the team responsible for the new SDK have been working very closely together. This was necessary because the migration required a constant feedback loop: the SDK had to be adapted to the requirements of the new app, while the app also had to adjust to the evolving SDK.
With the SDK now mature enough for the current phase and the mobile app moving into internal testing, the sync engine rewrite is becoming the next major focus for the backend team.
Sync is one of the hardest parts of a cloud storage product. Real-world user setups are messy. Devices go offline. Files change from multiple places. Some folders contain only a few files, others contain hundreds of thousands. Operating systems report file changes differently. Network conditions change. Users expect everything to resolve cleanly anyway.
The goal of the rewrite is to make synchronization more reliable, more consistent, and easier to reason about in real-world usage. That includes better change detection, better queueing, clearer conflict handling, more predictable retry behavior, and more robust handling of difficult edge cases.
The new sync engine also depends on the new caching system. Search is already using that cache now, and the sync rewrite will build on the same underlying work. This is one of the reasons why Global Search, the Rust SDK, and the sync engine are so closely connected. A better cache does not only make search more complete. It also gives us a stronger basis for detecting changes, comparing local and remote state, and making sync behavior more predictable.
A lot of performance work is part of this as well. During testing, we looked at very large item counts and intentionally difficult scenarios to understand where bottlenecks appear. In some cases, that led us below our own codebase and into the open source libraries we depend on.
We have also been making contributions to upstream open source projects where it makes sense. Some of these are smaller fixes or improvements, while others are more performance-focused. One visible example is an open pull request to a Rust database library we use, aimed at improving performance in large insertion scenarios. That work helps our own projects, but it can also benefit other developers using the same library.
This is worth mentioning because it shows how we want to build Filen. We do not want to simply accept avoidable limitations in the stack if we can improve them properly. When we find bottlenecks or missing pieces in the tools we depend on, we try to fix them at the right level, and when possible, contribute those improvements back upstream.
Infrastructure and stability
There is also good news on the infrastructure side.
In the last combined update, we talked quite openly about the pressure that followed Black Friday: sustained traffic, background rebalancing, expansion planning, and a hardware market that has been harder to predict than usual. That was a stressful phase internally, and it required a lot of careful work.
The situation is now much better.
The storage cluster is in a significantly healthier state again, and the balancing work that was necessary after the high-growth period has moved forward very well. There will always be infrastructure work in the background, and some future expansion steps will again create internal movement while they run. But compared to the phase we described at the start of the year, we are in a much more comfortable operational position now.
That is important because infrastructure should ideally be invisible to users. Nobody wants to think about cluster balancing, placement groups, hardware lead times, or maintenance windows. The goal is simply that Filen remains fast and reliable while we continue to grow.
We are still watching the hardware market closely. Availability and lead times remain less predictable than we would like, but the work done over the past months puts us in a better position to deal with that reality. The general approach stays the same: scale carefully, keep enough buffer, and prioritize reliability over short-term decisions.
Abuse prevention and registration protection
Another topic that stayed relevant after the free account changes is abuse prevention.
The changes we made earlier this year helped, and the overall feedback from the community was mostly understanding. But automated abuse attempts did not simply disappear. We still see suspicious signup patterns, automated registrations, and attempts to misuse the platform in ways that create load or operational risk.
This is not only about free storage. Large-scale automated registrations can also affect other systems. For example, if many activation emails are sent to low-quality or invalid addresses, that can hurt email deliverability. And email deliverability matters because normal users need to reliably receive account emails.
So we made additional adjustments to registration protection. The goal is not to make signup harder for normal users. The goal is to stop automated misuse before it creates bigger problems for the platform, support, email delivery, or other users.
We are handling this carefully because the balance matters. Filen should remain accessible and privacy-respecting. At the same time, we need to protect the service from automated abuse. Those two things can both be true, and most of our work in this area is about finding the right balance.
Security page and responsible disclosure
We also updated how we present and handle security reports.
Our public bug bounty and security page is now live in its updated form, and the older bug bounty framing has been adjusted. We still value responsible disclosure, and we absolutely want real security researchers to report serious issues to us. That part has not changed.
What has changed is the environment around public bounty programs. Over the last months, we have seen a growing number of low-effort, AI-generated, or template-based submissions that appear to be sent in bulk. Many of them look polished at first glance, but once reviewed, they often turn out to be unverified, non-reproducible, not security-relevant, or simply wrong.
To be very direct: this creates a real problem. A public bounty program can unintentionally motivate a quantity-over-quality approach, where people submit large numbers of weak reports and hope that one of them results in a payout. For our engineers, that still means reading, checking, reproducing, and dismissing reports that often should never have been submitted in the first place. That time is then missing for actual security work, product development, and the serious reports that deserve proper attention.
This is why we changed the wording and expectations around responsible disclosure. We want to remove the incentive for automated report farming and low-effort submissions, while keeping the door open for genuine security research. A useful report should be specific, reproducible, and clearly security-relevant. It should include a working proof of concept, explain the real impact, and show that the reporter made a reasonable effort to verify the issue and rule out false positives before sending it to us.
We also want to be clear that we cannot promise payouts for every submission. Rewards, where applicable, need to be tied to real security impact, clear reproduction steps, and the value of the finding. Minor bugs, theoretical issues without a practical exploit path, automated scanner output, or AI-written reports without proper validation cannot be treated the same way as serious responsible disclosure work.
This will remain a dynamic process. The current changes are a first step to reduce the flood of low-quality reports and make the process healthier for everyone involved. If we see that further adjustments are needed, we will make them. The goal is not to discourage security research. The goal is to make sure real reports do not get buried under mass-generated noise.
Security remains one of the most important parts of Filen. If someone finds a real vulnerability, can reproduce it, and can clearly show why it matters, we absolutely want to hear about it. We just need a process that protects our team from report spam while giving serious findings the attention they deserve.
Customer satisfaction survey
We also completed the customer satisfaction survey we mentioned in the last status update.
The survey is now closed, and the results have been reviewed internally. We read support tickets, social media comments, and community discussions every day, but a survey gives us something different: a broader and more structured view of how users feel about Filen.
That is useful for both development and support. It helps us understand what is working well, where users still feel friction, and which topics matter most for the future of the product. Sometimes survey results confirm things we already suspected. Sometimes they show us that a topic is more important than we thought. Both are valuable.
We are currently deciding whether to turn the results into a public summary again. If the community is interested, we can publish a separate post with the general findings, similar to what we have done in the past. Of course, we would not publish anything personal or sensitive. The idea would simply be to share the broader trends and explain what we take from them.
More broadly, we are still interested in ideas on how to improve communication between us and the community. Status updates, standalone posts, surveys, social media, support, and community discussions all serve different purposes. If you have thoughts on how we can make updates clearer, more useful, or easier to follow, we are always happy to hear them.
Marketing and creator campaigns
Another area that moved forward is marketing.
We are currently preparing a new creator campaign and are already talking to several creators. A campaign like this needs more than just a link and a short briefing. Filen is a privacy-first, zero-knowledge cloud storage provider, and that needs to be explained properly. What matters to us most is that these partnerships still feel honest. We are specifically looking for creators who have either already used Filen themselves, or who are willing to engage with the product deeply enough to genuinely stand behind what they tell their community.
That is why we have been working on a dedicated sponsoring package. It includes info material about Filen, content guidelines, design assets, product footage, visual inspiration, and other material that should make the collaboration easier while keeping the message accurate.
We also spent time thinking about the call to action side of these campaigns. Most creator sponsorships work better when there is a clear reason for viewers to check out the product right away. That can be a special offer, a creator-specific link, or a limited campaign. For Filen, this needs to be handled carefully because tracking, offers, and abuse prevention all need to fit together. But we are very optimistic that our affiliate program and promo code tool could return later this year.
There is no big public launch date to announce here. We are already in the practical preparation phase, and some parts are moving in parallel. The important point is that we are approaching this in a structured way instead of just copying generic sponsorship formats that do not really fit Filen.
Closing words
That’s it for this combined update.
April and May were again defined more by groundwork than by big releases, but this time a lot of that groundwork is starting to turn into concrete next steps. The new mobile app is ready for internal testing, the Rust SDK migration is becoming real across products, Global Search is moving onto the new caching foundation, the sync engine rewrite is becoming the next major focus, and infrastructure is in a much healthier place.
As always, thank you for your support, your patience, and your trust. We know that not every update can be full of big visible releases, but this kind of groundwork is what makes the bigger steps possible later. We will keep building carefully, keep communicating as clearly as we can, and keep making decisions that support Filen in the long run.
Until the next update,
Team Filen
