# Utilising Digitalocean spaces (s3 storage) for remote content-storage **URL:** \ **Category:** Questions\ **Tags:** v5\ **Created:** [December 16, 2025, 2:09pm UTC](https://forum.getkirby.com/t/utilising-digitalocean-spaces-s3-storage-for-remote-content-storage/35096 "2025-12-16T14:09:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Studio.dier](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.getkirby.com/studio.dier/32/11289_2.png) [@Studio.dier](https://forum.getkirby.com/u/Studio.dier)\ **Post date:** [December 16, 2025, 2:09pm UTC](https://forum.getkirby.com/t/utilising-digitalocean-spaces-s3-storage-for-remote-content-storage/35096/1 "2025-12-16T14:09:34Z")
Hello! I’m currently re-structuring my hosting strategy. Recently I’ve started deploying Kirby (as headless backend) to Digitalocean droplets using [ploi.io](http://ploi.io), which works like charm! Now I would like to host multiple instances for clients on the same droplet/server. Since the content-folder takes up most of the space it would mean that I’d have to resize eventually to get more space. that got me thinking about decoupling the content-folder and put those in a more ‘static’ s3-bucket. That got me looking into DigitalOcean’s solution called ‘Spaces’. When I read the Kirby-docs it seems like there is the possibility to reconfigure the folder-structure, and thus… can we do this with the content-folder? Has anyone experience with this use case? I’ve found this old post about with a similar question for Kirby-3: > [@Content folder on S3/DigitalOcean bucket?](https://forum.getkirby.com/t/content-folder-on-s3-digitalocean-bucket/12187): > > Hello! Congratulations on the new release; I plan on licensing a copy of Kirby 3 in very short order. Does anyone have experience with storing Kirby’s /content folder in object storage such as an Amazon S3 bucket or a DigitalOcean Spaces droplet? I see that all of Kirby 3’s roots are configurable ([https://getkirby.com/docs/reference/roots/content](https://getkirby.com/docs/reference/roots/content)), but was wondering if anyone in the community has had experience with this sort of paradigm. Thanks! ---
**Author:** ![tobimori](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.getkirby.com/tobimori/32/13333_2.png) [@tobimori](https://forum.getkirby.com/u/tobimori)\ **Post date:** [December 24, 2025, 12:11pm UTC](https://forum.getkirby.com/t/utilising-digitalocean-spaces-s3-storage-for-remote-content-storage/35096/2 "2025-12-24T12:11:57Z")
It will be too slow, not worth investing the time ---
**Author:** ![Studio.dier](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.getkirby.com/studio.dier/32/11289_2.png) [@Studio.dier](https://forum.getkirby.com/u/Studio.dier)\ **Post date:** [January 15, 2026, 10:57am UTC](https://forum.getkirby.com/t/utilising-digitalocean-spaces-s3-storage-for-remote-content-storage/35096/3 "2026-01-15T10:57:03Z")
Just for my understanding… On which end will it be slow? Since the url’s of the assets (images, videos, files) would be replaced with it’s corresponding url from the bucket. so in theory it will just change the link and the client wouldn’t notice. Or do you mean that the Kirby backend would be slow to with assets-managment? Would you have suggestion for another strategy I can look into? ---
**Author:** ![tobimori](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.getkirby.com/tobimori/32/13333_2.png) [@tobimori](https://forum.getkirby.com/u/tobimori)\ **Post date:** [January 15, 2026, 11:36am UTC](https://forum.getkirby.com/t/utilising-digitalocean-spaces-s3-storage-for-remote-content-storage/35096/4 "2026-01-15T11:36:17Z")
Everything will be too slow, since every request would have to read the content (txt) files. If you want to just use it for assets storage it’s easier and you can take a look into virtual files: [Virtual files | Kirby CMS](https://getkirby.com/docs/guide/virtual-content/virtual-files) You’d still store a ‘1px’ image on the actual server in addition to the content (txt) files so it doesn’t have to read everything from the S3 API which is always slow.