DEV Community: Ze Horta

Does a GPU let you fit more users on a shared Linux desktop server? I measured it

Ze Horta — Thu, 29 Oct 2026 18:41:32 +0000

I'm building Waydesk, a free, open-source remote desktop service for Debian and Ubuntu. The goal is narrow: a light, responsive RDP service where every account on a server gets its own desktop, built on Sway and Wayland.

Standard RDP, so people connect with the client they already have (Windows App, mstsc, Remmina, FreeRDP). Nothing to install on their side.
One complete desktop per account: a headless Sway session with a bar, dock, launcher, file manager, terminal and browser. It is assembled from Sway and a Qt shell rather than shipped as one GNOME or KDE package. Sessions persist when you disconnect.
Aimed at shared servers: labs, courses, support desks, small teams, and service providers who run Linux servers for others, anywhere a ready desktop per person on a server you already run is easier than a laptop each.
No GPU required, but one is used when there is one.

The usual alternatives are a full desktop environment (GNOME, KDE, Xfce) behind xrdp, or VNC. "Light" and "responsive" are claims, so I wanted numbers behind them. The question that decides whether this is practical: how many people fit on one server? And the one I most wanted to answer: does a GPU change that answer?

I tested both on rented servers by adding simulated users one at a time until the server refused one. Short version: memory decides how many fit, and the GPU did something different from what I expected. I did not compare against other remote-desktop stacks, so these numbers show what Waydesk does, not that it beats anything.

First, what limits you: memory

Every logged-in user keeps a session alive, with their programs open, whether or not they're looking at the screen. So the number that counts is how many accounts are logged in, not how many are typing.

Per user, measured:

Kind of user	Memory each
Desktop only	about 0.4 GB
Plus Chromium with three pages	about 0.7 GB
Heavy: Chromium, a 300,000-row spreadsheet, VS Code	about 1.6 GB

And how many fit, without a GPU:

Server	Result
4 GB	5 users with a browser
8 GB	9 users with a browser, or 8 heavy users
23 GB, 12 cores	12 heavy users; the 13th was refused

Without protection the 4 GB server crashed at five users: the kernel's out-of-memory killer shut down parts of people's desktops. Two things fixed it: a new login is turned away when too little memory is free (someone already logged in is never kicked out for a newcomer), and compressed swap (zram) squeezes idle memory about 4.5 to 1. On the 8 GB server that took heavy users from 6 to 8. The details are in the measurements.

In these runs the programs were opened and then left idle, so they are best-case numbers.

The GPU test

For this I used a dedicated Intel i7-7700 (4 cores, 8 threads) with its integrated HD 630 GPU and 64 GB of memory. The users were active, not idle. Each one had:

Chromium on a page that scrolls by itself,
a terminal typing and printing output,
LibreOffice Calc with a 300,000-row sheet and VS Code, both receiving keystrokes,
window switches every 15 to 30 seconds,
a muted looping video for every fourth user, GIMP on a large image for every fourth, and sound for three.

The RDP clients ran on a separate cloud server in the same data centre, so decoding 20 video streams wouldn't eat the CPU I was measuring.

I ran the ramp twice: GPU on (sway rendering on the GPU, VAAPI hardware H.264 encoding, zero-copy capture) and GPU off (software rendering, OpenH264 on the CPU).

Active heavy users	CPU, GPU on	CPU, GPU off	free memory, GPU on	free memory, GPU off
1	23 %	21 %	53.4 GB	53.6 GB
10	47 %	45 %	32.7 GB	35.8 GB
20	50 %	69 %	10.7 GB	16.6 GB
24	(22nd refused)	94 %		8.5 GB

GPU on: 21 users fit, the 22nd was refused. GPU off: 24 fit, the 25th was refused. Memory ended both runs.

So the GPU did not let more people in, but it changed two other things:

It took the load off the CPU. With the GPU, CPU use stayed near 50 % from 15 users on. Without it, it climbed 3 to 4 points per user. The capture-and-encode processes used 4.8 % of the machine with the GPU at 20 users, against 15.4 % without (about 70 % less). On a machine with more memory, that headroom should fit more users. I estimated that; I did not measure it.
It used more memory. 2.24 GB per user against 1.95 GB, because an integrated GPU takes its buffers from system RAM. A card with its own video memory wouldn't do this, but I haven't tested one under many users.

Nothing failed in either run: no errors, no dropped frames, no out-of-memory kills.

Where the GPU clearly matters: graphics-heavy pages

I also ran a full-screen WebGL noise page for each user, which is a deliberately brutal case:

Users	Frame rate per page (median)	GPU render engine
1	60	53 %
2	60	93 %
3	47	100 %
6	20.5	100 %
12	17	100 %

An HD 630 gives two users 60 fps, and then its render engine is the limit: the frames get shared about evenly. Lighter pages share among more people.

And without a GPU the page didn't animate at all in the browser. As Waydesk starts Chromium, it uses --disable-gpu when there is no usable render node. If your users need WebGL, a GPU isn't an optimisation but a requirement.

What happens when the GPU can't help

Two cases I checked, because they affect real deployments:

GPU present but no hardware encoder. The session still works; the H.264 encoding falls back to OpenH264 on the CPU, and the log says so. One user on the WebGL page went from 2.9 % of the machine (VAAPI) to 12.3 % (CPU encoder). This is what an NVIDIA card looks like to VAAPI, so I wrote an NVENC encoder as well: on an RTX 4000 SFF Ada, one user ran at 61 fps with the card's encoder 4 % busy. That was one user on one card; several users on one card are not measured. It also needed NVIDIA's own 615 driver, since Debian's 550 can't give a headless sway its buffers.
Render node present but the GPU switched off. An OpenGL app (glxgears) falls back to the CPU and opens; a Vulkan one (vkcube) fails to present its window. On a server with no render node at all, vkcube opened on Mesa's software drivers. Odd, but worth knowing before you debug it.

What I'd tell someone sizing a server

Memory first. About 0.4 to 0.5 GB per session for the desktop, plus what the programs use, plus about 1 GB for the system. Heavy users cost 1.6 to 1.85 GB.
Add zram and size it to RAM, and refuse new sessions when the machine is full instead of degrading everyone.
A GPU buys CPU headroom, not more users, unless you have the memory to use it. Graphics-heavy work (WebGL, video, 3D) is where it becomes necessary.
Check your own hardware. My results were one user off between a VM and a real server.

What I didn't measure

How fast individual applications feel with and without the GPU (apart from WebGL), the delay between a click and its picture, a discrete card under many users, AMD, long runs (each ramp took about 45 minutes), and far-away clients on slow links with many users.

Waydesk is early and has had no independent review. If you want to try it, or compare your numbers with mine, the testing checklist is in issue #1. The full method, tables and raw data are in docs/MEASUREMENTS.md and docs/measure-data/.

Multi Shelter Manager: an open-source, multi-tenant app for animal shelters, with Laravel 13, Livewire and a one-click demo

Ze Horta — Sat, 24 Oct 2026 17:03:28 +0000

Small animal shelters usually run on spreadsheets, paper cards and WhatsApp groups. Vaccination dates get lost, nobody knows which cage a dog is in, and adoption requests arrive as Instagram DMs.

Multi Shelter Manager is a free, MIT-licensed web app that replaces all of that. Several shelters share one installation, each fully isolated, and it already runs three real shelters, from the Azores to Lisbon and Porto. It's made in Portugal with Laravel 13 and Livewire.

👉 Try it now: https://demo.focinhos.pt (one click, no sign-up, you get your own sandbox shelter)

Code: https://github.com/zhoorta/multi-shelter-manager

What it does

Pets: identification, microchip, health, photos, and a status (available / adopted / ...) worked out automatically.
Facilities → wings → cages: model the physical space, see occupancy, and always know where every animal is.
Vaccinations and treatments with due dates and daily e-mail reminders.
Adoptions, sponsorships, volunteers, members and their fees.
Foster families and cat colonies (CED/CER programmes).
Reports for managers, with printable yearly activity report.
Public adoption portal with filters and an application form.
10 languages and light/dark mode.

The interesting parts, technically

Multi-tenancy by shelter_id. One database, one install, any number of shelters. Every shelter-owned table carries a shelter_id, and a trait scopes queries so a shelter can never see another's data. Users can belong to several shelters with a different role in each (admin, manager, staff, viewer).

Livewire + Flux UI + Tailwind. Classic split components (class plus Blade view), no JavaScript framework. Tables, modals and forms come from Flux, so the UI stays consistent with very little custom CSS.

Auditing for free. A Blameable trait fills created_by, updated_by and deleted_by on the core models, which matters when volunteers and staff share an account of what happened to an animal.

Ten languages from day one. All UI strings go through __() with a JSON file per locale. Retrofitting this later is painful; doing it from the start was cheap.

A public demo that costs almost nothing. People should be able to try it without installing anything, but a shared demo database turns into a mess in minutes. So in DEMO_MODE every visitor gets a throwaway shelter cloned from a template, and a demo:prune command (every 10 minutes) deletes old ones. It runs in a single FrankenPHP container with SQLite on a RAM-backed volume, behind nginx on a small server. A restart wipes everything and re-seeds in about a minute. The one rule to remember: every new shelter-owned table must be added to the sandbox's table list, or it won't be copied or cleaned up.

Why open source

Shelters have no budget for software, and each country has a handful of tools that are either paid per animal or abandoned. This is a cause project, not a business: if it helps another shelter, great. If you run one, or know someone who does, the README has a quick start, and the docs folder has a step-by-step guide with screenshots.

Feedback welcome

Feedback is very welcome, from other Laravel developers (what would you do differently in the tenancy layer?), and from anyone who works with shelters (what's missing?). Issues and PRs are open.

Demo: https://demo.focinhos.pt
Repo: https://github.com/zhoorta/multi-shelter-manager

Full-text search in Laravel on both SQLite and MySQL: FTS5, FULLTEXT and one interface

Ze Horta — Mon, 19 Oct 2026 16:48:22 +0000

TL;DR: you can add real search inside files to a Laravel app without Meilisearch or Elasticsearch. Keep the extracted text in one table, give each database its own small driver (FTS5 on SQLite, a FULLTEXT index on MySQL and MariaDB), and join the results to your normal tables so permissions stay in one place.

I'm building Ferrite, a self-hosted file server. It runs on SQLite by default and on MySQL or MariaDB if you prefer. People wanted to find a file by a word inside it, not only by its name, and I did not want the install to grow another service. This is how I did it, including the places where the two databases differ enough to bite.

(If you can run a search service, Laravel Scout with Meilisearch or Typesense is a perfectly good answer. This is for when you can't, or won't.)

One table, keyed on the content

Extracted text goes into a node_contents table, one row per distinct content (the file's SHA-256), not per file. Two identical files are read once. A queued job on its own search queue reads the file after it is stored: text files directly (the first 2 MB, valid UTF-8 only) and PDFs through pdftotext. A row has a status (indexed, skipped with a reason, or failed), so a binary file or a broken PDF is not retried forever.

The index is built on top of that table, and that is the part that differs per database.

One interface, two drivers

The search code does not know which database it is on. It asks for a driver:

interface ContentSearchDriver
{
    // Narrow $nodes to the files whose text matches, best first, with a `snippet` column.
    public function match(Builder $nodes, string $term): ?Builder;

    // The snippet with the matched words marked.
    public function present(string $snippet, string $term): string;
}

return match (DB::connection()->getDriverName()) {
    'sqlite' => new SqliteContentSearch,
    'mysql', 'mariadb' => new MysqlContentSearch,
    default => null,   // other databases keep the table but have no content search
};

match() receives a query that is already limited to what the user may see, and adds the join, the full-text condition, the ranking and the snippet. More on that in a moment.

SQLite: an FTS5 table kept in step by triggers

FTS5 is built into SQLite. I use an external content table, so the text is stored once (in node_contents) and the FTS table only holds the index. Three triggers keep it in step:

DB::unprepared("create virtual table node_contents_fts using fts5(
    text, content='node_contents', content_rowid='id',
    tokenize='unicode61 remove_diacritics 2')");

DB::unprepared("create trigger node_contents_ai after insert on node_contents begin
    insert into node_contents_fts(rowid, text) values (new.id, coalesce(new.text, ''));
end");
// plus an 'after delete' and an 'after update' trigger that remove the old entry first

remove_diacritics 2 makes reuniao find reunião, which matters if your users are not English-speaking. The query itself is short, with bm25 for ranking and snippet() for the excerpt:

return $nodes
    ->join('node_contents as nc', 'nc.sha256', '=', 'nodes.sha256')
    ->join('node_contents_fts', 'node_contents_fts.rowid', '=', 'nc.id')
    ->whereRaw('node_contents_fts match ?', [$query])
    ->select('nodes.*')
    ->selectRaw("snippet(node_contents_fts, 0, char(1), char(2), '…', 18) as snippet")
    ->orderByRaw('bm25(node_contents_fts)');

I mark the matched words with two control characters (char(1) and char(2)), so the view can escape the whole snippet as HTML and only then replace the markers with <mark>. That keeps the snippet safe even when the file's text contains <script>.

MySQL and MariaDB: a FULLTEXT index

On MySQL the migration is one line: $table->fullText('text'), on a LONGTEXT column. The query uses boolean mode:

return $nodes
    ->join('node_contents as nc', 'nc.sha256', '=', 'nodes.sha256')
    ->whereRaw('match(nc.text) against (? in boolean mode)', [$query])
    ->select('nodes.*')
    ->selectRaw('substring(nc.text, greatest(locate(?, nc.text) - 60, 1), 240) as snippet', [$words[0]])
    ->selectRaw('match(nc.text) against (? in boolean mode) as content_rank', [$query])
    ->orderByDesc('content_rank');

Three differences from SQLite:

No snippet function. I cut a 240-character window around the first word in SQL and mark the words in PHP afterwards, with the same control characters, so the view code is identical.
Short words and stopwords. InnoDB ignores words shorter than three characters and a built-in list of stopwords. If you make such a word required (+the*) the search can come back empty. I don't rely on the behaviour: I drop those words from the query, and if nothing is left I return no content matches.
Ranking differs. bm25 on SQLite, InnoDB's relevance score on MySQL. The order of results is not the same, and I documented that instead of pretending.

Never let the user's text reach the search syntax

Both engines have a query language (quotes, OR, NEAR(, -, *, : in FTS5). If you pass the raw input through, plain OR ( becomes a syntax error, or worse, a way to run operators you did not intend. So the input is reduced first to letters and digits:

preg_match_all('/[\p{L}\p{N}]+/u', mb_strtolower($term), $found);

Each word then becomes "word"* on SQLite or +word* on MySQL: every word required, each matched as a prefix. The tests throw odd inputs at it ("plain, col:plain, NEAR(plain words), *, a lone quote) and assert that nothing throws.

Permissions stay where they were

The index never decides who sees what. Search starts from the same visibility query as the file list (your own files, plus everything below folders shared with you, trashed items excluded) and then match() narrows it. A user only ever gets snippets of nodes they could already open, even though identical content is stored once across users.

$query = $driver->match(
    $this->visibleTo(Node::query(), $user)
        ->where('nodes.type', NodeType::File)
        ->whereNull('nodes.trashed_at'),
    $term,
);

Testing on both databases

The search tests are one Pest file. By default it runs against in-memory SQLite. To run the same file on MySQL or MariaDB you point the suite at an empty test database, and CI does that with a MySQL service container.

One trap: an InnoDB FULLTEXT index only sees committed rows, and Laravel's RefreshDatabase wraps each test in a transaction. On MySQL every search found nothing. The fix, in the test file only: commit at the start of each test and empty the tables afterwards.

// An InnoDB FULLTEXT index only sees committed rows, so on MySQL these tests commit
// the transaction the suite wraps them in and empty the tables afterwards instead.
$this->commits = in_array(DB::connection()->getDriverName(), ['mysql', 'mariadb'], true);

if ($this->commits) {
    DB::commit();
}

I ran the file on SQLite, MySQL 8.4 and 9, and MariaDB 11.

Gotchas to know about

Accents on MySQL depend on the collation. With utf8mb4_unicode_ci (Laravel's default) accents and case are ignored. With a _bin or _as_cs collation they are not.
The queue worker has to listen to the new queue. Mine is queue:work --queue=default,search. Without it the extraction jobs are queued and never run. With the sync queue driver, PDFs are better left to a scheduled command so a slow PDF can't hit a time limit inside a request.
PDFs need pdftotext (poppler-utils). Scanned documents have no text layer, so there is nothing to index. I did not add OCR.
The index holds the file's text unencrypted in your database. If that matters, make indexing switchable. Mine is one environment variable.

What I would do differently

If you already run Meilisearch or Typesense, use them through Scout. Typo tolerance and facets are something this setup does not give you.
A Postgres driver would be a third class behind the same interface (tsvector), and the structure makes it easy to add. I did not need it.
I would test the very large case (millions of rows) before promising anything. This is built for a person or a small team.

The code is open source (AGPL-3.0). If you want to read it rather than my summary:

The drivers: SqliteContentSearch and MysqlContentSearch
The design notes: docs/content-search.md
The project: github.com/zhoorta/ferrite, with a live demo (throwaway account, wiped after an hour) where you can upload a text file or PDF and search for a word in it.

Questions or corrections are welcome in the comments.

Disclosure: I built Ferrite and I use an AI coding assistant (Claude) while developing it; I review and test what it writes. An AI assistant also helped me draft this article, and I edited it and checked the claims against the code. I chose the "AI-assisted" option when publishing.

Ferrite: self-hosted file storage in Laravel, Livewire and Flux UI (open source, with a live demo)

Ze Horta — Tue, 13 Oct 2026 15:15:22 +0000

I've built a small self-hosted file server called Ferrite. It is web-only file storage for one person or a small team that you run on your own server, and it is open source (AGPL-3.0). You can try it without installing anything: demo.ferrite.stackcare.pt (one click, a throwaway account that is wiped after an hour; small images, PDFs and text only).

Why I built it

I come from a sysadmin background, and I wanted private file storage that is boring to run: one app, a database, a folder, and nothing else to keep alive. Most of what I found was either a full cloud suite or a sync tool, and I wanted something smaller. I also wanted to see how far a small, opinionated Laravel app could go when it only does one job.

It is deliberately narrow: no sync clients and no WebDAV. You open it in a browser, upload, preview, share and search.

What it does

Uploads that survive bad connections. Chunked and resumable, so multi-gigabyte files and flaky Wi-Fi are fine. Whole folders by drag and drop.
Previews and sharing. Images, PDF, video, audio and text open in the browser. Share by link with a password or an expiry, with other users as viewer or editor, or give a guest an upload-only link to one folder.
Search inside your files. Names, and the text of text files, Markdown, code, CSV and PDFs, with highlighted snippets.
A small API for scripts and other apps: personal access tokens made under Settings > API tokens, optionally limited to one folder, with list, Range download and chunked upload. Write tokens never replace or rename; a taken name answers 409.
When a name already exists, it asks: replace (same file, its links and favorites stay), keep both, skip, or cancel.
Users and storage. Several users with quotas, 2FA and passkeys; files on a local folder, S3 or SFTP.
Fifteen themes, because I like retro interfaces: Classic Mac, Amiga, a Nokia 3310 screen, Miami Vice and more. They are optional, and you can switch them in the demo under Settings > Appearance.

How it is built

Laravel 13, Livewire, Flux UI, Tailwind and Pest, with about 550 tests. A few decisions I found interesting:

The slow part never blocks a request. The last upload chunk only queues a job. The job hashes the file and copies it to its disk, which can take minutes on SFTP or S3. It runs on its own queue connection with a retry_after longer than the job's timeout, so a long copy is never started twice.
Search works on SQLite and MySQL. It uses FTS5 on SQLite and a FULLTEXT index on MySQL and MariaDB, behind one small interface. The CI runs the search tests on both.
Serving users' files from your own origin needs care. Files only display inline for an allowlist of safe types, everything else is a download, with nosniff on every response. There is a written security review in the repository.
Names and folders live only in the database. The files themselves are blobs under random keys, so renaming or moving something never touches the disk.

Honest limits

No versioning, sync clients, WebDAV, office previews or real-time collaboration.
S3 is tested up to the adapter, not against a real S3 service. SFTP was tested on a Hetzner Storage Box.
No independent security audit yet, and no encryption at rest (it is planned).
It is young: version 0.3.0.

What I'd like from you

If you try the demo or read the install docs, tell me what felt confusing or broke. I'd especially like to hear where the install guide lost you, and whether the security notes in the repository (docs/security.md) cover what you would worry about before putting your files on it.

Try it

Demo: https://demo.ferrite.stackcare.pt
Project page: https://ferrite.stackcare.pt
Code: https://github.com/zhoorta/ferrite (AGPL-3.0)
Install: docker compose up -d, or a normal Laravel install. The README has both routes.

Disclosure: I built Ferrite and I use an AI coding assistant (Claude) while developing it; I review and test what it writes. An AI assistant also helped me draft this post, and I edited it and checked the claims against the code. I chose the "AI-assisted" option when publishing.

Resumable uploads in Laravel without a package: chunks, offsets and a queue job

Ze Horta — Thu, 08 Oct 2026 16:18:26 +0000

TL;DR: send a file in 5 MB chunks, let the server's offset decide where to continue, and do the slow final copy in a queue job on its own queue connection, with a retry_after longer than the job. That is the whole design, and it needs no package.

Uploading a 2 GB file through a normal PHP form is a bad idea. A proxy times out, PHP's limits get in the way, and one dropped connection at 95% means starting again. When I built a self-hosted file server (Laravel, Livewire, Flux UI) I wanted uploads that survive all of that, including a final copy to a remote disk (SFTP, S3) that can take minutes.

If you need interoperability with existing clients, the tus protocol is the standard and there are Laravel packages for it. What follows is a simpler, application-specific protocol that I could test end to end.

The protocol: four endpoints

All uploads, big or small, use the same flow, so there is no separate "simple" path to maintain.

POST /uploads with the file name, size and a fingerprint. The server creates an uploads row and answers with an id, the current offset (0) and the chunk_size. Starting the same file again resumes the unfinished upload instead of creating a new one.
PATCH /uploads/{id} with the raw chunk as the request body and an Upload-Offset header.
GET /uploads/{id} returns the state: receiving, processing, done or failed.
DELETE /uploads/{id} cancels.

Chunks are appended to a temporary file named after the upload id. The default chunk size is 5 MB, so each request only has to fit your proxy's body limit, not the whole file. upload_max_filesize stops mattering because the body is not a form upload, but keep post_max_size and your proxy's body limit above the chunk size.

The client: ask the server where you are

The browser slices the file and sends one chunk at a time. The key idea is that the client never trusts its own idea of progress. The server's offset is the truth.

const end = Math.min(state.offset + state.chunk_size, file.size);

const response = await fetch(`/uploads/${state.id}`, {
    method: 'PATCH',
    body: file.slice(state.offset, end),
    headers: { 'Content-Type': 'application/octet-stream', 'Upload-Offset': String(state.offset) },
});

if (response.status === 409) {
    // Out of step: the server says where it really is, and we carry on from there.
    state = { ...state, ...(await response.json()) };
    continue;
}

If a request fails, the client waits (1, 2, 4 seconds and so on, up to five retries), asks GET /uploads/{id} for the real offset and continues from it. That one rule gives you resume after a network drop, after a tab reload (the fingerprint, here the file's last-modified time, finds the unfinished upload) and after a duplicated request.

The server: one writer at a time

Two requests for the same upload must never write at the same time, and a chunk must only be accepted at the exact offset the server expects:

$lock = Cache::lock("upload:{$upload->id}", 120);

if (! $lock->get()) {
    return response()->json($this->state($upload), 409);
}

try {
    $upload->refresh();
    $header = $request->header('Upload-Offset');
    $offset = is_numeric($header) ? (int) $header : -1;

    // Wrong offset, or already handed over: tell the client where we are.
    if (! $upload->isReceiving() || $offset !== $upload->offset) {
        return response()->json($this->state($upload), 409);
    }

    // append the chunk to the temporary file at that offset ...
} finally {
    $lock->release();
}

A 409 carrying the real state is not an error to the client. It is how it finds its place. I also refuse a chunk that would go past the declared size (413), and every chunk request checks that the upload belongs to the current user.

Finishing: do the slow part in a queue job

When the last chunk arrives, the request does one thing: it marks the upload processing, queues a job and answers 202 at once. The job hashes the file (SHA-256), sniffs the MIME type from the content (the client's claim is ignored), copies it to its disk under a random key and creates the database record.

Why not in the request? On a remote disk the final copy can take minutes, and a proxy will cut the request long before that. Meanwhile the browser shows "Storing the file…", starts sending the next file, and polls GET /uploads/{id} (every second at first, slowing to five) until the state says done or failed.

The job has two unusual settings:

class FinalizeUpload implements ShouldQueue
{
    public int $tries = 1;          // a half-finished copy is cleaned up; the user retries
    public int $timeout = 21600;    // six hours
    public bool $failOnTimeout = true;

    public function __construct(public string $uploadId)
    {
        $this->onConnection('uploads');
    }
}

The gotcha that cost me the most time: `retry_after`

A queue worker puts a job back on the queue if it has not finished within the connection's retry_after seconds. The default is 90. A copy that legitimately takes an hour would be picked up and started a second time while the first is still running.

The fix is a separate queue connection just for these jobs, with a retry_after larger than the job's timeout, and a worker started on that connection:

// config/queue.php
'uploads' => [
    'driver' => 'database',
    'table' => 'jobs',
    'queue' => 'uploads',
    'retry_after' => 21700,   // above the job's 21600 s timeout
],

php artisan queue:work uploads --queue=uploads --tries=1 --timeout=0

The first uploads is the connection name, not the queue name. A worker started without it would use the default connection and its 90-second window.

Other things that bit me

Clean up on failure. Note the destination key on the upload row before you write, so a crash halfway can still remove the partial file. A failed job deletes the temporary file and any file that no database record uses, and marks the upload failed with a reason the browser can show next to a Retry button.
Quota. I check it when the upload starts and again, inside a transaction that locks the user's row, when the file is stored. Parallel uploads can each pass the first check, and the second check keeps the books right.
Temporary space. The temp folder needs room for the largest file times the uploads in flight, and the target disk needs the file again.
Deploys. Workers keep the old code in memory, so restart them after every deploy. A scheduled prune command removes unfinished uploads older than a day and gives up on jobs that died.
Proxy limits. The proxy's body limit and timeout only have to cover one chunk. Long timeouts are for downloads, not uploads.

What I would still do differently

If you need to resume across different clients and tools, use tus instead of a custom protocol.
Hash on the client if you want to skip uploads of files you already have. I did not.
I tested the remote path against one SFTP server (a Hetzner Storage Box) and a local OpenSSH server, not against a real S3 service, so treat that part as less proven.

The full implementation (controller, job, the browser store) is open source in the project where I built this: Ferrite. The upload design is written up in docs/uploads.md.

*Disclosure: I wrote the code. An AI assistant helped me draft and edit this article, and I checked every claim against the code.

DEV Community: Ze Horta

Does a GPU let you fit more users on a shared Linux desktop server? I measured it

First, what limits you: memory

The GPU test

Where the GPU clearly matters: graphics-heavy pages

What happens when the GPU can't help

What I'd tell someone sizing a server

What I didn't measure

Multi Shelter Manager: an open-source, multi-tenant app for animal shelters, with Laravel 13, Livewire and a one-click demo

What it does

The interesting parts, technically

Why open source

Feedback welcome

Full-text search in Laravel on both SQLite and MySQL: FTS5, FULLTEXT and one interface

One table, keyed on the content

One interface, two drivers

SQLite: an FTS5 table kept in step by triggers

MySQL and MariaDB: a FULLTEXT index

Never let the user's text reach the search syntax

Permissions stay where they were

Testing on both databases

Gotchas to know about

What I would do differently

Ferrite: self-hosted file storage in Laravel, Livewire and Flux UI (open source, with a live demo)

Why I built it

What it does

How it is built

Honest limits

What I'd like from you

Try it

Resumable uploads in Laravel without a package: chunks, offsets and a queue job

The protocol: four endpoints

The client: ask the server where you are

The server: one writer at a time

Finishing: do the slow part in a queue job

The gotcha that cost me the most time: retry_after

Other things that bit me

What I would still do differently

The gotcha that cost me the most time: `retry_after`