Eagle V5 Is in Development: What We've Been Building

If you've been following Eagle recently, you may have noticed that things have been quieter than usual.

It's been several months since our last major Blog update. During that time, we've continued maintaining Eagle V4, fixing issues, improving compatibility, and releasing necessary updates, but there haven't been many major new features or announcements.

From the outside, we understand how that can look. Some users have even asked us directly:

Is Eagle still being developed?

The answer is yes.

In fact, a significant part of our development effort has gradually shifted toward something much larger:

Eagle V5.

We haven't talked about V5 very often because it is still actively being developed, and we don't want unfinished plans to turn into promises too early.

This isn't a release announcement, and we're not ready to share a launch date yet.

But we do think it's time to explain more clearly what we've been working on, why it has taken so long, and why V5 eventually became such a substantial rebuild.

Eagle V4 Is Still Being Maintained

Before talking about V5, we want to make one thing clear:

Eagle V4 is not being abandoned.

We continue to maintain V4 and work on stability, compatibility, and issues that affect everyday use.

Some ideas that were originally explored as part of V5 have also already made their way back into V4 through plugins.

AI Search, AI Actions, Eagle Skills, and Eagle MCP are examples of this.

Instead of keeping these capabilities behind a future major release, we've tried to make them available to existing Eagle users earlier whenever possible.

At the same time, years of development have made one thing increasingly clear: there are limits to how far we can continue extending Eagle's current foundation.

Eagle was first released in 2017. Since then, libraries have become much larger, workflows have become more complex, and the ways people want to access and work with their assets have changed considerably.

Some of the things we want Eagle to support next are no longer simply feature problems.

The foundation underneath the product itself needs to change.

Why V5 Became a Ground-Up Rebuild

When we first started planning the next major version of Eagle, we didn't necessarily expect it to become such a deep rewrite.

But as development continued, we realized that many of the limitations we were running into came from assumptions built into Eagle's original design.

Today, much of Eagle is centered around the idea that one desktop application is the center of the entire system.

The interface you see, the logic behind it, the current state of the library, and many data operations are all tightly connected.

That design has served Eagle well for many years.

But it becomes increasingly restrictive when we start thinking about multiple windows, multiple users, different accounts, access from other devices, browsers, AI agents, and eventually platforms such as iPad or other mobile devices.

Trying to add all of those possibilities directly onto the current architecture would mean constantly working around limitations that were never designed for them.

And some of these problems cannot truly be solved by simply attaching another plugin to V4.

For example, if a future Eagle library can be modified by different users, automated workflows, or multiple AI agents at the same time, we need the system to understand who is acting, what they are allowed to do, what they changed, and how those changes should be recorded.

Those capabilities are difficult to add cleanly later if they are not part of the core architecture from the beginning.

So instead of continuing to stretch the same foundation indefinitely, we decided to rebuild it.

In V5, the part of Eagle responsible for actually managing a library is separated from the interface you use to interact with it.

That may sound technical, but the idea is quite simple:

Your assets can still live on your own computer, and that computer itself can be responsible for managing your Eagle library.

For most users, this may not feel dramatically different in everyday use.

You can still open Eagle on your computer and use it like a normal desktop application.

The important difference is what becomes possible underneath.

Your Computer Can Be the Host

When we talk about accounts, access from multiple devices, synchronization, or even concepts such as a "server," it's easy to assume that Eagle is preparing to launch its own cloud service.

That's not what we're describing.

The V5 architecture we're building does not require your library to be moved into an Eagle-operated cloud.

V5 is still being designed around data that you control.

By default, your assets can remain on your own computer or storage devices, while the core part of Eagle that manages the library can run directly on that machine.

Most users don't need to think of that computer as a "server" at all.

You can simply continue opening Eagle and using it as you do today.

The difference is that, if you want to, the same library can eventually be accessed in more flexible ways.

For example, someone with a little networking knowledge could allow another computer or device on the same local network to connect to the Eagle library running on their main computer.

More technical users could also choose to configure their own remote access using a VPN, fixed IP, or other networking methods.

In that situation, your own computer is effectively the host for the library.

A small team, for example, could keep one computer in the office to store and manage a library, while authorized members connect to it.

A home user could do something similar with a computer they manage themselves.

The important point is:

None of this requires you to upload your library into cloud storage provided by Eagle.

What we want to provide is more flexibility, not move everyone's data onto our servers.

Accounts Do Not Mean Your Assets Must Live in the Cloud

V5 will also need an account system.

The reason is straightforward.

If more than one person or device can access the same library, Eagle needs to know who is using it and what that person is allowed to see or change.

That's why accounts become necessary for identity and permissions.

But this does not mean:

"Having an Eagle account" means "your assets must be stored in Eagle's cloud."

Those are two separate things.

The account determines who can access something.

The actual files can still live on your computer, hard drives, NAS, or other storage that you manage yourself.

Similarly, when we talk about "synchronization" or "multiple devices," what we mean is that different devices could eventually work with the same Eagle library.

We are not announcing that Eagle plans to upload everyone's libraries into our own cloud storage.

This Is Not a Move Toward Subscription

Accounts, multiple devices, and a substantially new architecture can also raise another concern: does this mean Eagle is preparing to become a subscription product?

That is not what we're building.

Eagle V5 is not being designed around a subscription service, and moving Eagle toward a subscription model is not the direction we prefer.

The purpose of this architectural change is something else:

to give users more flexibility in how Eagle runs, where their data lives, and what devices or tools can access their assets in the future.

We are not rebuilding Eagle to become SaaS, and we are not doing this to move users' data from their own computers into an Eagle-operated cloud.

V4 and V5 Are Fundamentally Different

There is an important consequence to rebuilding Eagle this way that we also want to be transparent about.

Eagle V5 is not simply Eagle V4 with its internal parts gradually replaced.

It is being built on a fundamentally different architecture.

That gives us much more freedom to solve problems that are difficult within V4, but it also means V4 and V5 are not directly compatible at the architectural level.

When V5 eventually becomes available, moving from V4 will therefore not be as simple as installing a normal update and continuing as though nothing changed.

We plan to provide tools to help users import and migrate their existing V4 libraries into V5.

Our goal is to make that process as simple and reliable as possible, while reducing the amount of work users need to do.

But because the underlying systems are genuinely different, some data may need to be converted, and some existing workflows or behaviors may need to be adapted to the new architecture.

We think it's better to be clear about that now rather than suggest that two fundamentally different systems can somehow be completely interchangeable.

This is also part of why V5 takes time.

We're not only building a new system. We also have to think carefully about how nearly a decade of existing Eagle libraries, data, and workflows can move safely into that new foundation.

Much of the Work Is Happening Where You Can't See It

A long development cycle can make it seem as though we must be building a huge number of visible new features.

In reality, much of our work over the past months has focused on things users may never directly see.

We've been separating parts of Eagle that were previously tightly connected, rebuilding how different parts of the application communicate, and rethinking how libraries themselves should be managed.

This kind of work doesn't always produce exciting screenshots.

Sometimes months of development result in something that looks almost identical on the surface.

But underneath, the system is becoming very different.

Once that foundation is in place, many capabilities that used to require complicated workarounds become much more natural to build.

Multiple Windows Become Much More Practical

Multiple windows are a simple example.

Eagle today was fundamentally designed around one desktop application managing one library.

Properly supporting multiple independent windows is not just a matter of opening another window.

Those windows need to understand the same library state, respond to changes consistently, and avoid interfering with one another.

V5's new architecture makes it much more natural for multiple windows to work with the same library.

For example, you might keep reference material open in one window while organizing assets in another, or work across different views without constantly changing the state of a single interface.

It's a relatively simple example, but it shows why we're investing so much effort in the foundation rather than continuing to bolt individual features onto V4.

Multiple Users and Accounts Become More Practical

The same architectural change also gives us a much better foundation for multiple users and multiple accounts.

Historically, Eagle has been designed mainly around one person using one local library on their own computer.

That simplicity is one of Eagle's strengths, and we don't want to lose it.

But there are also situations where people need more flexibility.

For example, separating personal and work environments, or eventually allowing multiple people to work with the same library under controlled permissions.

A team could eventually keep a library on one computer and allow several authorized members to connect to it.

That computer could be in an office or at home.

The important part remains the same:

the computer and the data can still belong to you.

This doesn't mean every possible collaboration feature will appear in the first release of V5.

What matters is that the new architecture will no longer prevent us from building those features properly.

Every Important Change Should Have a Clear History

Once a library can be used by multiple people, automated workflows, or even AI agents, another question becomes much more important:

Who changed what, and when?

Imagine a team with User A and User B, while Agent A and Agent B are also helping organize the library.

Someone changes tags, moves a group of files, edits custom properties, or deletes content.

If the system can only tell you that "something changed," but not who caused that change, managing the library becomes much harder as the number of users and automated actions grows.

That's why V5 will treat a complete audit log as an important part of the underlying system.

The system can record which user or agent performed an action, when it happened, what content was affected, and what changed.

This is not only useful when something goes wrong.

It is also an important foundation for safe collaboration, automation, and AI agents.

As AI becomes capable of organizing, tagging, or modifying large numbers of assets, we don't think users should only see the final result.

You should be able to know what the AI actually did.

And once important actions have clear origins and records, it becomes possible for us to build stronger version history, rollback, safety controls, and approval workflows on top of that foundation in the future.

This is another example of something that cannot be solved properly by simply attaching a plugin to V4.

It needs to exist in the core system responsible for managing data and executing changes.

Letting Different People Describe Assets in Their Own Way

Another direction we've cared about for a long time is custom properties.

Eagle is used by people in very different fields.

Some people use it to manage design assets, others organize photography, video, research material, product information, or internal team libraries.

Even the same person may need completely different information for different projects.

A design team might want fields such as "Client," "Project Stage," or "License Status."

A photographer might care more about "Photographer," "Location," or "Usage Expiration."

Other users may need fields that are unique to their own workflow.

We cannot decide in advance what every user's data structure should look like.

So in V5, we plan to introduce Custom Fields, allowing users to add structured information to assets based on the way they actually work.

This may sound like one feature, but to us it represents a much broader direction:

Eagle should not force everyone to organize assets using one fixed data model. It should be flexible enough to adapt to different people, teams, and even different projects.

Once that custom information becomes a proper part of the library, it can also be searched, filtered, used in automation, and eventually understood by AI agents.

For example, if a team creates fields such as "Project Status," "Review Result," or "License Expiration," those fields could eventually be used not only by people organizing assets, but also by authorized automation or agents following the team's own rules.

This is what we want V5 to become:

not a system that defines one correct workflow for everyone, but a flexible foundation that can adapt to very different ways of working.

More Possibilities Beyond the Desktop

Another important result of this architecture is that Eagle no longer has to be limited to a single desktop application.

The Windows and macOS applications can continue to be the main way most people use Eagle.

But in the future, a browser on the same network could potentially access the same library.

A user who chooses to configure remote access could potentially connect from somewhere else.

An iPad application could eventually be built on the same foundation.

The same applies to other mobile devices.

Again, none of these possibilities inherently require an Eagle cloud service.

The library can still remain centered around your own computer.

We're deliberately using words like could and eventually here.

These are examples of what the architecture makes possible, not a list of features guaranteed for the first release of V5.

AI Agents Can Become Another Way to Work With Eagle

There's also another type of user of an Eagle library that barely existed when Eagle was first designed in 2017:

AI agents.

Over the past year, we've already started exploring this direction through Eagle MCP and Eagle Skills.

Today, AI can already search, understand, and perform certain operations on assets stored in Eagle.

But we think this is only the beginning.

As people increasingly work alongside AI, an asset library shouldn't only be usable by the person currently using the mouse and keyboard.

It should also provide safe and controlled ways for other tools or AI systems to search, understand, organize, or modify assets when they have permission to do so.

V5 gives us a much better foundation for this.

In the future, the Eagle desktop app, a browser, another device, or an AI agent could all become different ways of working with the same Eagle library.

But for us, the important part is not simply that "AI can control Eagle."

The important part is that AI actions should be identifiable, permissioned, and traceable just like human actions.

If an agent changes one hundred assets, the system should know which agent performed those actions, when they happened, and exactly what was changed.

If different agents are responsible for different tasks, they should only be allowed to perform the actions they have permission to perform.

This is why accounts, permissions, audit logs, custom fields, and the new data architecture are not separate features.

Together, they form the foundation we want V5 to have.

For us, that's much more meaningful than simply adding an AI chat box somewhere inside Eagle.

We want Eagle itself to become a better foundation where people, devices, automated tools, and AI agents can all work with the same assets under clear and controlled rules.

This Doesn't Mean Everything Will Arrive at Once

Whenever we talk about what a new architecture makes possible, it's easy for future possibilities to sound like promised features.

That's not what we're announcing here.

Multiple windows, multiple users, multiple accounts, browser access, iPad, mobile devices, remote access, AI integrations, and new collaboration models are examples of things that become much more practical once V4's architectural limitations are removed.

They should not be read as a checklist of features guaranteed for the first release of V5.

Our immediate priority is still the foundation.

We want to make sure the new architecture is reliable, the core Eagle experience remains fast and dependable, and the path from V4 to V5 is something we can confidently provide to existing users.

Once that foundation is solid, we can build much more aggressively on top of it.

So, When Will V5 Be Released?

We know this is probably the question many people want answered most.

Right now, we don't have a release date we're ready to announce.

There is still substantial work ahead.

And because V5 has become a much deeper change than a conventional major update, we don't want to create an artificial deadline and then compromise the foundation simply to meet it.

We'll share more when we have something concrete enough to be useful.

Until then, Eagle V4 will continue to be maintained.

And where it makes sense, we'll continue bringing useful capabilities to existing users rather than unnecessarily holding everything for V5.

Eagle Is Still Moving Forward

If Eagle has seemed unusually quiet recently, it's not because development has stopped.

It's because a large part of our work has moved beneath the surface.

After nearly a decade of building Eagle, we reached a point where continuing to add features to the same foundation was no longer enough for the things we want to build next.

So we're building a new one.

That comes with tradeoffs.

V5 will be fundamentally different from V4, and moving between them will require a real data migration rather than an invisible upgrade.

But that architectural change also gives us room to rethink some of Eagle's oldest limitations and build a better foundation for multiple windows, multiple users, custom fields, complete audit history, more devices, AI agents, and entirely new ways of working with a library.

Through all of this, one important principle remains unchanged:

Eagle should continue to work around data you own and devices and storage you control. We want to give you more ways to access, manage, and work with your assets—not take control of them away from you.

There's still a lot of work ahead.

But Eagle is very much still being developed, and V5 is the foundation we're building for its next chapter.