Nextcloud answers the collaboration question – but the storage beneath it decides compliance and cost. Your objects live exclusively in the Frankfurt datacenter, operated under German jurisdiction with a DPA per Art. 28 GDPR. No CLOUD Act reach, no transatlantic data journey, no opaque egress model. Access runs over the real S3 endpoint https://de-fra.i3storage.com (region de-fra) – the same SigV4 signature your tools already speak, just with a provider you and your clients can hold legally accountable.
As primary storage the bucket becomes the instance's sole data store: Nextcloud writes every file as an object while metadata stays in the database. This is the path for new instances and for scaling without local disks – but it must be set before the first login and cannot be swapped afterwards. As external storage you mount the bucket as an additional drive via the External Storage app – visible per user or group, attachable or detachable at any time, ideal for existing instances, project shares, or moving large datasets. Both paths talk to the same endpoint https://de-fra.i3storage.com; they differ only in who owns object management – Nextcloud itself or the external-storage layer.
In the customer portal create a bucket (e.g. nextcloud-primary) and an API key pair (access key + secret). Access runs solely through these SigV4 credentials – treat the secret like a root password and issue a separate key pair per tenant.
In config/config.php add the objectstore block with the S3 class: bucket, key, secret, hostname = de-fra.i3storage.com, port = 443, use_ssl = true, region = de-fra and use_path_style = true. The hostname is always de-fra.i3storage.com – the full endpoint reads https://de-fra.i3storage.com.
With use_path_style = true Nextcloud addresses the bucket as a path: https://de-fra.i3storage.com/<bucket>. Virtual-hosted style https://<bucket>.de-fra.i3storage.com works too – for Nextcloud setups path-style is the most robust default because it needs no bucket wildcard DNS.
Set autocreate = true so the empty bucket is initialised on first access, and finish installation before the first user logs in. An occ maintenance:mode window prevents write conflicts during the switch.
Upload a test file and verify with aws s3 ls or rclone lsf against https://de-fra.i3storage.com (region de-fra) that the object appears in the bucket. Strong read-after-write guarantees the upload is immediately consistent to read.
Full endpoint: https://de-fra.i3storage.com · region de-fra. For external storage use the same values in the app dialog (Amazon S3): hostname de-fra.i3storage.com, port 443, region de-fra, SSL on, path-style on.
Nextcloud relies on a freshly written object being immediately and fully readable – during chunked uploads of large files, photo previews, or multi-client sync. Eventual-consistency storage causes file errors, vanishing uploads and broken previews here. Our object storage delivers strong read-after-write consistency for new objects from the first byte – exactly the guarantee Nextcloud assumes. Without it, an S3 backend simply isn't production-grade for Nextcloud.
Important for expectation management: file versions, trash bin, shares, group permissions and server-side encryption are handled by Nextcloud itself – not the object store. That's an advantage, not a gap: you keep your familiar Nextcloud features independent of the storage. Enable the Server-Side Encryption app and objects are encrypted by Nextcloud client-side before they reach the bucket – key custody stays with you. For immutability, don't rely on storage features but on a second copy following the 3-2-1 principle (e.g. a separate backup bucket or an external target).
| Primary Storage | External Storage | Backup target | |
|---|---|---|---|
| Role | Sole data store of the instance | Additional drive per user/group | Second copy in 3-2-1 |
| Setup | config.php objectstore block | External Storage app (S3 dialog) | occ/backup tool, s3fs or rclone |
| When to set | Before first login, cannot be swapped | Attachable/detachable anytime | Separate bucket, own key |
| Ideal for | New instances, full scaling | Existing instances, project shares | Ransomware resilience, DR |
| Consistency | strong read-after-write (required) | strong read-after-write | strong read-after-write |
| Endpoint | https://de-fra.i3storage.com | https://de-fra.i3storage.com | https://de-fra.i3storage.com |
One bucket plus a dedicated API key pair per customer – if a key compromises one instance, every other tenant stays untouched. Clean separation without shared credentials, cleanly billable per bucket.
1 TB egress is included per TB of storage, each additional TB is a fixed rate – never “free”, but never a surprise. You price managed plans on a stable margin instead of hyperscaler egress roulette.
You buy storage from €2.49/TB and resell it as part of your managed Nextcloud package including operations, support and SLA. Storage is your cost base – the value-add and markup are yours. High CLV with low churn.
DPA per Art. 28, Frankfurt DC only, 100% green power, TLS transfer – arguments you pass straight to clients in healthcare, legal and public-sector settings. Sovereignty sells, especially in DACH B2B.
Via s3fs or rclone mount you attach buckets as a filesystem – for migration scripts, bulk imports or backup jobs outside Nextcloud. The S3 endpoint stays the same: https://de-fra.i3storage.com, region de-fra.
Deliver publicly shared objects via the CDN (DACH/Europe) with low latency; IPv4 and IPv6 are natively available. Ideal for media shares and public downloads served from Nextcloud.
The most expensive line item in any cloud-storage offer isn't the terabyte – it's unpredictability. When a customer suddenly syncs, shares and downloads, egress models make the bill explode, and your margin with it. Our model ends that: storage from €2.49/TB, 1 TB egress included per TB, each additional TB at a fixed rate. You know your cost base before the sale and build managed plans with a markup that carries the margin. Because access runs purely through SigV4 keys and signed URLs, you don't operate complex access infrastructure – one key pair per tenant, one bucket per instance, done. Less operational overhead, more contribution margin. That's what turns managed Nextcloud on this foundation into a high customer-lifetime-value product rather than a bottomless support pit.
If Nextcloud creates previews only on demand, it triggers many small object reads and slows down gallery and file views. Install the Preview Generator app and run occ preview:generate-all once; at the same time cap the preview sizes in config.php to sensible edge lengths. That keeps your object access lean and the UI snappy.
Nextcloud manages the trash bin and file versions in the app layer – every retained version takes up space in the bucket. Set versions_retention_obligation and trashbin_retention_obligation to values that fit your cost frame so deleted files and old versions don't quietly inflate the bucket. That keeps per-tenant storage usage predictable.
Nextcloud splits large uploads into chunks and reassembles them server-side before the finished object is written to the bucket. Provide enough temporary space on the app server and generous upload limits in PHP and the web server. Strong read-after-write ensures every assembled object is immediately consistent to read.
Our experience speaks for itself: We have successfully completed migrations involving multiple petabytes of data and over 500 million files.