Use a Storage Server for your website: images, downloads, archives

On a web server, disk space is the most expensive asset you have. It sits on fast NVMe SSDs built for databases and PHP, and it gets noticeably more expensive with every gigabyte. At the same time, that space holds things which never need that speed: original photos, video files, download archives, old backups.

A Storage Server costs a fraction of that and takes exactly this load off your hands. This article shows what is worth moving off, which protocol works from the web server, how the files reach your visitors securely, and where the limits are.

What is worth moving off, and what is not

The dividing line is simple: whatever is read rarely and transferred once in one large piece belongs on the storage. Whatever is loaded along with every page view stays where it is fast.

What a Storage Server is, and what it is not

A Storage Server is network storage with user accounts. You connect with credentials and read or write files. It is not object storage with public addresses and not a CDN.

In practice that means you cannot link an image in your page directly to the storage, because every access is authenticated. Your web server fetches the file and passes it on, or you generate time-limited download links yourself. How to do that cleanly is covered further down.

That sounds like a restriction, but it has an upside: nobody can grab your files by guessing addresses or by passing a link around. Access always runs through your application, and therefore through your rules.

The pattern that works in practice

Three steps, that is all there is to it:

1. Originals live on the storage. They are uploaded once and rarely touched afterwards.
2. Derived versions are created once and live on the web server. That means thumbnails, cropped variants, compressed versions. They are small, and they are needed on every page view.
3. Downloads run through your application. A small script checks the permission, fetches the file from the storage and sends it out.

Turn that around and fetch the thumbnails fresh from the storage on every request, and you have built yourself a slow website. The network latency per file adds up, and a gallery with forty images waits forty times.

Which protocol for which case

The most important decision is not a matter of taste but of your rights: on your own server you mount the storage as a directory, and every application can use it without knowing anything about it. How that works is described in Mount a Storage Server as a network drive.

On shared hosting you have no root rights, so mounting is out. There the way leads over WebDAV or SFTP from inside the application, and WebDAV is usually the smaller obstacle, because port 443 is practically never blocked.

Setting up access from PHP

For SFTP a pure PHP library is enough, no extension on the server is needed:

composer require phpseclib/phpseclib:~3.0

use phpseclib3\Net\SFTP;

$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
    throw new RuntimeException('Login failed');
}

// Upload a file
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);

// Read a file
$inhalt = $sftp->get('/bilder/2026/original.jpg');

For WebDAV, even the built-in curl extension is enough:

$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_USERPWD        => 'u123456-sub1:' . $passwort,
    CURLOPT_TIMEOUT        => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);

Both examples use a sub-account, not the main account. The next section explains why.

A separate sub-account for every purpose

Every Storage Server allows up to 100 sub-accounts, and that applies to every plan. Each one gets:

• its own home directory, which it cannot leave,
• its own password,
• its own protocol permissions, so for example SFTP only and no Samba.

For a website that means one sub-account for the web server, which may only use SFTP and only sees /web, and a second one for the backup, which only sees /backup. If the web server is ever taken over, the attacker does not get to the backups, because that account does not even know about them.

There is one limit: a sub-account does not get a space quota of its own. It stays inside its directory, but can fill the entire storage of the plan from there. If you really want to cap individual users, you need an application in front that takes care of it. Connect Nextcloud to the Storage Server shows exactly this setup.

Delivering downloads securely

The most common mistake is letting the credentials reach the browser, for example through a link containing the username and password. The right way is for your server to open the connection and pass the file through:

<?php
// Check the permission before anything else happens
if (!nutzer_darf_datei($_GET['id'])) {
    http_response_code(403);
    exit;
}

$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));

header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;

With very large files you are better off reading in blocks instead of loading everything into memory, otherwise the PHP memory limit breaks the download. Use ob_end_flush() for that and send the file out piece by piece.

If you expect many simultaneous downloads, bear in mind that every running download occupies a PHP process. Beyond a certain scale, something like that belongs behind your own server rather than behind shared hosting.

Backing up the website to the storage

This is the easiest way in, and it pays off immediately. With rsync you transfer only the changes:

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub2@u123456.storage.kernelhost.net:/backup/web/

For backups with deduplication and encryption, BorgBackup is the better choice, and it is available natively on the storage. On top of that come the snapshots of the storage itself as a second layer: depending on the plan 10, 20, 30 or 40 manual snapshots, plus the same number of automatic ones on a daily, weekly and monthly schedule.

The difference from a backup on the same server is the decisive one: a deleted or encrypted disk takes a local backup with it, a backup on separate storage survives.

Before you start: two switches

In the customer panel you will find the "Access Settings" button on your Storage Server. Two things have to be right:

• External Reachability has to be switched on, otherwise your web server cannot reach the storage over the internet.
• The protocol you want has to be enabled, so Samba for SMB, SSH for SFTP and rsync, WebDAV for the HTTPS route.

On newly ordered servers, all of this is already active. If you switch off what you do not need for security reasons, remember that this is exactly the most common cause of "it stopped working" later on.

Which plan fits

All Storage Servers are located in Germany, speak FTP, FTPS, SFTP, SCP, Samba, WebDAV and WebDAVs, come with rsync and BorgBackup natively and have IPv4 and IPv6. There is no setup fee, and billing is PrePaid with no minimum term. So you can start with 1 TB and grow later without moving anything.

For a sense of scale: 1 TB of additional space on a web server costs a multiple of 9.99 EUR per month depending on the provider, and it then sits on the same machine as the website. The storage next to it is not only cheaper, it is also separate.