linkding VPS requirements: RAM, CPU, disk, and when the plus image changes the size

Sizing guide

Our recommendations, derived from the sourced figures below. Not measurements.

Official requirements

What people report in practice

Individual reports, not controlled tests. Versions, hardware and settings differ, so treat these as data points, not guarantees.

• linkding idled at 148 MB of RAM and 566 MB of total Docker disk shortly after the documented install on a clean 2 vCPU / 8 GB VM. In the same sweep Wallabag read 58 MB and Karakeep, which also runs a browser for archiving, 679 MB

  Independent test of 96 self-hosted apps, Google Cloud e2-standard-2, 28 Sep 2026. Idle with no users or bookmarks; base image

  Blog SelfHost Atlas: Self-hosted app RAM usage, 96 apps measured (2026) · checked Nov 2, 2026

• A user saw the base container start at about 180 MB and reach 232 MiB after 10–12 hours. The maintainer found no leak: memory grows with the charset_normalizer caches used when fetching page titles and with cached templates, then levels off. "For an installation of the base image, memory usage should hover ... somewhere around 230 MB. For the plus image you should plan with around 1 GB of available memory"

  GitHub issue, Feb to Apr 2024, answered by the maintainer

  GitHub GitHub sissbruecker/linkding #634: Probable memory leak · checked Nov 2, 2026

• Containers jumped to about 8–9 GB within seconds of starting, with nothing else happening. The cause was uWSGI sizing itself to the host's open-file limit (one user's showed 1073741816). Setting UWSGI_MAX_FD=4096 or a Docker ulimit brought it down to about 160 MB idle and 170–180 MB in normal use

  GitHub issue, Apr 2023 to Nov 2024, many reports on Arch, Fedora and Raspberry Pi; fixed in the image by PR #990 (1.38.1, Feb 2025)

  GitHub GitHub sissbruecker/linkding #453: uwsgi causing excessive memory consumption · checked Nov 2, 2026

• With the container limited to 1 CPU and 256 MB, opening a 500 MB asset in the web UI got a uWSGI worker killed (signal 9), because the file was read fully into memory. Fixed in 1.47.0 by streaming assets

  GitHub issue, Aug 2026, with a reproduction; fix in PR #1482

  GitHub GitHub sissbruecker/linkding #1455: Asset view reads entire file into memory, causing OOM crash · checked Nov 2, 2026

• Choosing a web-page saver, one user wrote that linkding with headless Chrome "'eats' at least 1G of RAM". Replies suggested Readeck ("barely 30mb ram on sqlite") or pairing the base linkding with the SingleFile browser extension instead

  r/selfhosted thread, Sep 2026. Opinions, not measurements

  Reddit r/selfhosted: Which saver of web-pages to use? · checked Nov 2, 2026

What drives linkding's RAM use

A small Django app that levels off

The base image is two uWSGI workers plus a background task processor, and it idled at 148 MB in one test (SelfHost Atlas). Memory rises a little as page-title caches and templates fill, to about 230 MB, then stops growing (#634). The number of bookmarks barely matters for RAM; tens of thousands of rows are small for SQLite.

Chromium is the real cost

With the plus image, every new bookmark starts a headless Chromium to save the page. That's what needs the extra gigabyte (archiving docs), and a large import queues one snapshot per bookmark. If you only want snapshots sometimes, keep the base image and send pages from the SingleFile browser extension to linkding's API instead.

Disk: snapshots, previews and favicons

The install itself is about 566 MB of Docker disk for the base image (SelfHost Atlas); the plus image download alone is about four times the base one (Docker Hub). After that, the data folder grows with HTML snapshots, uploaded files and PDFs in assets, plus downloaded favicons and preview images (backup docs). We haven't measured a typical snapshot size, so watch du -sh data/assets for your first few weeks.

Gotchas on a VPS

• Old threads about 8 GB of RAM. Before 1.38.1, uWSGI could reserve memory for every possible file descriptor and use 8 GB or more at startup (#453). Current images set UWSGI_MAX_FD=4096 (PR #990). If you run an old pinned tag and see it, upgrade or set that variable yourself.
• Create a user, and don't leave the login open. The image starts with no account, so either run createsuperuser or set LD_SUPERUSER_NAME and LD_SUPERUSER_PASSWORD (docs). Leaving the password empty creates a user that can only sign in through an auth proxy. Put the login behind HTTPS, or keep it private and reach it through a tunnel such as Pangolin.
• Port 9090 is public by default. The example compose file publishes 9090:9090 on every interface (compose file), and Docker's published ports bypass UFW (Docker docs). Bind it to 127.0.0.1:9090:9090 behind Caddy or Nginx.
• Login fails behind Nginx. Nginx rewrites the Host header by default, which breaks linkding's CSRF check, so login and other forms fail. Add proxy_set_header Host $host and X-Forwarded-Proto, or set LD_CSRF_TRUSTED_ORIGINS to your URL. Caddy needs no changes (reverse proxy docs).
• Bookmarking internal URLs since 1.47. 1.47.0 added SSRF protection, so linkding no longer fetches titles, previews or PDF snapshots from private and local addresses (options). If you bookmark services on your own network or VPN, list those hosts or ranges in LD_ALLOWED_INTERNAL_HOSTS. HTML snapshots are only partly covered: the browser can still load embedded resources from internal hosts.
• Cap uploads on a small plan. Upload size is unlimited by default. On a 512 MB or 1 GB VPS set LD_REQUEST_MAX_CONTENT_LENGTH, which the docs suggest to stop large uploads running the server out of memory (options), and give the container a memory limit so a bad request restarts linkding instead of freezing the VPS.
• Back up with full_backup, not cp. python manage.py full_backup writes a ZIP of the database, snapshots, favicons and previews; copying db.sqlite3 while it runs isn't transaction safe (backup docs). With PostgreSQL you back up the database and the data folder separately. Copy the ZIP off the server.

Cheapest plans that fit

linkding, base image, SQLite, on its own: 1 GB RAM and 1+ vCPU

Threshold: Published readings of 148–232 MB for the container. Not yet measured by us (source). Only plans with at least 1 vCPU are listed.

linkding base image next to a proxy and other small apps: 1 GB RAM and 1+ vCPU

Threshold: Our estimate, not a measurement: about 230 MB for linkding plus room for neighbours (source). Only plans with at least 1 vCPU are listed.

linkding plus image with server-side HTML snapshots: 2 GB RAM and 1+ vCPU

Threshold: Docs: Chromium needs "at least 1 GB of RAM"; 2 GB adds headroom for the OS and the web app. Our estimate (source). Only plans with at least 1 vCPU are listed.

Prices checked Oct 28, 2026 on each provider's official pricing page. EUR prices converted at the ECB rate of Oct 27, 2026 (1 € = $1.115) only for ranking. See all plans on the cheapest 4 GB VPS page.

Related pages

• Vaultwarden requirements: Another light single-container app; a password vault and a bookmark manager fit together on a 1 GB VPS.
• Pangolin requirements: Keep a private linkding off the public internet and reach it through a Pangolin tunnel instead.
• Uptime Kuma requirements: Watch your bookmark server and its certificate from a separate small VPS.
• Mealie requirements: A recipe manager with a similar small footprint; both import from URLs you save.
• Paperless-ngx requirements: For documents rather than web pages; its OCR, not linkding, decides the RAM if both share a server.
• Coolify requirements: linkding runs as a plain Docker image, so a Coolify server can deploy it; Coolify itself needs more RAM than linkding.