Dokan hosting for a marketplace with many sellers writing at once.
A single-admin store has one person editing products. A marketplace has dozens, all authenticated, all writing, none of them cacheable.
Everything a multivendor marketplace asks of a host.
Every vendor is a logged-in user doing administrative work, which is the traffic a normal store barely has.
One vendor never sees another
Vendor dashboard and order URLs bypass the page cache completely. A cached dashboard shows one seller another seller's orders, which is the failure a marketplace cannot survive.
Sized for concurrent authors
Dozens of people editing products simultaneously is a write pattern a single-admin store never produces, so the connection pool is sized for it rather than for page views.
Storage counted per vendor
One seller uploading thousands of product images otherwise consumes the allowance every vendor shares. Limits are applied per account and enforced on upload.
Payouts that calculate on time
Commission and withdrawal jobs run on the platform scheduler. Vendors notice money before they notice anything else, and cron that waits for traffic pays late.
Signup that is not a spam target
Open seller registration is attacked from the day it opens, and each fake vendor creates a user, a store and a public page. Rate limits run at the edge.
See the marketplace, not just the store.
The numbers that matter here are per vendor: who is uploading, whose payouts ran, and which stores are actually active.
- Per-vendor storage and activity
- Payout run status
- One-click admin login
- Restore any daily backup from the dashboard
Fifty vendors editing at once.
Marketplace load is authenticated and write-heavy on both sides - shoppers on the front, sellers in the back - and neither half can be served from cache.
What we change for Dokan
These differ from a standard WooCommerce site on the same plan, and each follows from the store having many authors rather than one.
| Setting | What we do | Why |
|---|---|---|
| Vendor dashboard URLs | Bypass the page cache entirely | A cached vendor dashboard shows one seller another seller's orders, which is a data breach rather than a performance bug. |
| Database connections | Pool sized for many simultaneous authors | A marketplace has dozens of people editing products at once, which a store with a single admin never generates. |
| Vendor media | Storage and upload limits applied per vendor account | One seller uploading thousands of images otherwise consumes the allowance the entire marketplace shares. |
| Withdrawal and commission jobs | Run on the platform scheduler | Payout calculations that depend on visitor-triggered cron run late, and vendors notice money before they notice anything else on the site. |
| Vendor registration | Rate-limited at the edge | Open seller signup is a spam target from launch, and every fake vendor creates a user account, a store and an indexable page. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can vendor dashboards be cached at all?
How many vendors can the site support?
Can I stop one vendor filling the disk?
Do vendor payouts run reliably?
How do you handle fake vendor signups?
Run your marketplace on a host that expects many sellers.
Free migration, dashboards that stay private, and payouts that calculate on schedule.