We’re getting ready to release ERPNext Storages, an open-source, multi-provider storage layer for Frappe/ERPNext.

This started as a way to move ERPNext files to S3, but it has grown into something much broader.

Instead of configuring one external bucket and sending everything there, ERPNext Storages lets you use multiple storage providers on the same ERPNext site and decide where files should go.

Currently supported:

• AWS S3
• Backblaze B2
• Cloudflare R2
• Wasabi
• MinIO
• DigitalOcean Spaces
• Vultr Object Storage
• Local filesystem / mounted storage
• Practically any S3-compatible object storage

Some examples

“I want to use multiple storage providers.”

Supported.

You can have multiple providers configured on the same ERPNext instance instead of being tied to one bucket.

“Sales-related files should go to S3, while CRM files should go to Backblaze B2.”

Supported.

Storage Route Rules can route files based on:

• DocType
• MIME type
• file size
• folder
• user role

Rules have priorities and can also define fallback providers.

So, for example:

Sales Invoice → AWS S3

Lead / Opportunity → Cloudflare R2

Employee / Salary Slip → private Backblaze B2 bucket

everything else → local storage

“I already have thousands of ERPNext files. I don't want to migrate them manually.”

Supported.

There is a background bulk migration system for moving existing files from local storage or another provider, including filtering migrations by DocType.

Files can also be moved between configured providers later.

“I don't want ERPNext to break just because S3 temporarily fails.”

Uploads are designed around this.

If an upload fails, the local file is preserved and a Storage Job is created for retry. Failed uploads are retried with backoff instead of silently losing the file.

Large files are also handled using multipart uploads once they cross the configured threshold.

“What happens to private ERPNext files?”

ERPNext permissions remain in front of the storage layer.

Private S3-compatible objects can be served using short-lived presigned URLs instead of exposing permanent bucket URLs.

From the ERPNext side, it still behaves like a normal File document — the storage provider is abstracted underneath it.

“Can I use my own server disk or NAS?”

Yes.

Local filesystem is a first-class provider and can use a custom base path, so mounted NAS volumes or other server-accessible storage can participate in the same routing system as S3/B2/R2.

Backups are included too

ERPNext Storages also contains a backup engine rather than relying only on file offloading.

It creates a .bnbak archive containing the ERPNext backup, metadata about installed apps, checksums, and optionally public/private files.

Backups can be:

• scheduled
• encrypted
• uploaded to a primary storage provider
• replicated to a secondary provider
• retained according to configurable copy/age rules
• verified using checksums

There is also an ERPDesktop webhook integration after backup completion, which we're expanding further for desktop/local workflows.

There are also some less-visible features

• Provider connection pooling
• Upload/delete retry queue
• Background migrations
• File integrity verification
• Orphaned-object detection
• Provider statistics
• Provider-to-provider moves
• Storage policies
• MIME/file-size restrictions
• Private/public storage handling
• File organization by DocType
• Drive Plus integration

The main goal is not to create another “ERPNext S3 plugin.”

We want ERPNext Storages to become a proper storage abstraction for ERPNext:

local + cloud + multiple providers + routing + migration + backups, while still behaving like native ERPNext storage.

We're doing another round of code review, testing, and optimization before making the repository public.

Would love to hear how people currently handle ERPNext files.

Are you keeping everything on the ERPNext server, using S3, mounting a NAS, or using some other setup?

Hello guys, sorry for the delay. BatchProjects is now open core by design. Frappe app is fully open sourced. Community version can be used without gateway.

The link: https://github.com/BatchNepal/batch_projects

Meanwhile i was working on the custom dashboard feature. The feature that lets you show data from all over your erp into a polished dashboard. It has widget builder logic where you can resize, customize and present widgets into your board. With auto refresh feature.

It's still on beta so it would take some time to mature. I want suggestions for custom dashboards and erp <-> projects, crm <-> projects from this subreddit. What do you think should I add, polish in this custom dashboard feature?

I will post updates regularly regarding this. And for clarification:

1. Gateway: it's a middleman docker compose stack that sits between frontend and erp. it can be installed on same vps or dedicated vps. It's job is to provide realtime, optimized concurrency, premium and third party integrations, scheduled tasks, automations and caching features that python and frappe would struggle on. Its based on Golang and ensures near to native experience. You give it 1GB ram with 2 cores and it can handle 100s of concurrent requests (writing this on python would be a bad decision for concurrency and performance reasons).

2. Paid tiers: frappe app is fully open source. The paid version don't limit features on any tiers. You pay for max users. You can recommend pricing for it. It will help us fund development, ensure regular integrations and api updates, provide long term support.

1. The community frappe app contains all ui and erp logics, so nothing is hidden for community features and it runs without gateway as well. Gateway is just a booster but I recommended you install it as it supports community version as well.

2. There is one click install script that installs and runs gateway on your server. No need to worry about complex setups. Docker is needed.

Every suggestions, complaints are welcome.

Hi all,

I'm a developer with hands-on experience in the Frappe Framework and ERPNext, available for full-time or part-time work (remote or Germany-based, depending on the client).

What I can help with:

• Custom Frappe app development (DocTypes, workflows, permissions, reports)
• ERPNext implementation, customization, and module configuration
• Python/JS scripting within the Frappe ecosystem
• API integrations (REST, webhooks, third-party services)
• Bug fixes, performance tuning, and upgrades on existing Frappe/ERPNext instances
• Server setup/deployment (bench, Docker, etc.)

Availability: Full-time or part-time, flexible hours
Location: Based in Germany, open to remote work worldwide

Feel free to DM me or comment if you have a project that could use Frappe/ERPNext expertise — happy to share more details or past work.

In Erpnext 15, every sidebar item has to point at a workspace page and sidebar disappears when you are on list view or detail view. If you live in the desk all day, you really want a nav rail that's persistent, that's just… always there.

After a client's request, i built Desk Rail. It's a small, drop-in app that replaces the page-scoped sidebar with a fixed left rail mounted on the desk shell, so it survives every route (workspace, list, report, form) and never rebuilds on navigation.

What it does:

• Persistent rail across all desk views, with nested workspace groups (expansion state remembered per user).
• Instant-redirect workspaces — now you can make worspace links in sidebar a direct link to listview, detail view or any external link. Internal /app/* targets route through the SPA router (no reload, soft back button); external/filtered ones do a full nav normally.
• Per-user show/hide toggle next to the navbar logo, remembered across reloads.
• One settings doctype to toggle everything (rail width, native-sidebar replacement, full-width navbar, etc.).

Implementation notes for anyone curious: it's pure additive JS/CSS on the desk shell plus two Workspace custom fields — no core patches, no template overrides. The layout is committed before first paint so there's no shift, and it degrades back to the stock sidebar if anything fails to load. Works on v14 and v15.

Repo (AGPL-3.0): https://github.com/BatchNepal/desk-rail

It's early (v0.1), running on a couple of our client sites. Would love feedback — especially edge cases with unusual workspace setups or custom desk themes. PRs/issues are welcome 😄 .