[{"data":1,"prerenderedAt":129},["ShallowReactive",2],{"seo-verification":3,"blog-host-paperless-ngx-on-your-own-vps-ma-en":6,"promo-bar-likely":128},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-host-paperless-ngx-on-your-own-vps-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":35,"sections":36,"ctaTitle":68,"ctaBody":69,"ctaButton":70,"ctaUrl":71,"relatedPosts":72},85,"host-paperless-ngx-on-your-own-vps",{"fr":12,"en":10,"ar":13,"es":14},"heberger-paperless-ngx","استضافة-paperless-ngx-على-خادمك-الافتراضي-الخاص-vps","alojar-paperless-ngx-en-un-vps","Host Paperless-ngx on Your Own VPS: Complete Guide 2026","Install Paperless-ngx on a VPS: Docker Compose, multilingual OCR, 2.x→3.x migration, Redis\u002FValkey incompatibility and automatic backup. Updated guide.",17,2,false,"2026-03-27T00:00:00+00:00","2026-09-08T02:42:11+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fheberger-paperless-ngx-poster.svg",{"categorySlug":25,"appSlug":34},"paperless-ngx","Paperless-ngx turns your scanned documents into a searchable archive. This guide covers installation, OCR configuration, common date and timeout issues on entry-level VPS, and the migration procedure from the 2.x branch to the 3.x series with its known incompatibilities.",[37,41,44,47,50,53,56,59,62,65],{"type":38,"title":39,"body":40},"h2","Why Paperless-ngx for Your Self-Hosted DMS","Paperless-ngx is the most active community fork of Paperless — a document management system (DMS) that indexes your PDFs and scanned images, extracts text via OCR, and lets you find them by keyword, date, correspondent or tag.\n\nCompared to alternatives (Mayan EDMS, OpenDocMan), Paperless-ngx stands out for its ease of installation (Docker Compose in under 10 minutes), its **Angular** web interface, and its multilingual OCR support via Tesseract.\n\nThe project is community-maintained and publishes regular releases — check the current version on the GitHub releases page before installing. The current branch is the **3.x** series; if you are starting from a 2.x instance already in service, read the \"Upgrading from 2.x to 3.x\" section below **before** touching your `docker-compose.yml`: v3 makes two previously inferred or implicit settings mandatory, and changes several default behaviours.\n\n**Typical use cases:**\n- Supplier invoice archive for a small business or SME\n- Personal or family medical records (prescriptions, test results, letters)\n- Document management for an association or property management\n- Contract and lease archive for a real estate agency",{"type":38,"title":42,"body":43},"Requirements and VPS Selection","Paperless-ngx is more resource-intensive than it appears, especially at import time. OCR processing of a multi-page PDF heavily loads the CPU — this is the main source of timeouts on small configurations.\n\n**Recommended minimum configuration:**\n- CPU: 2 vCPU (OCR processing is single-threaded per task, but several tasks can run in parallel)\n- RAM: 2 GB minimum; 4 GB for comfortable use\n- Storage: SSD, 20 GB minimum for the application + space for your documents\n- OS: Debian 12 or Ubuntu 22.04\u002F24.04\n\n**What causes timeouts on small VPS:** PDFs scanned at high resolution (300+ DPI) or with many pages (50+) can exceed the default `PAPERLESS_WORKER_TIMEOUT` (1,800 seconds). The dedicated section below covers the resolution.",{"type":38,"title":45,"body":46},"Installation with Docker Compose","The official recommended installation uses Docker Compose with three services: `webserver` (the application), `broker` (the task queue) and `db` (the PostgreSQL database).\n\n⚠️ **Download all THREE files, not just `docker-compose.yml`.** This is the most expensive installation trap on this page, because it fails **silently**. The official compose file declares `env_file: docker-compose.env`: container settings are read from **that** file. The directory's `.env`, on the other hand, holds a single line — `COMPOSE_PROJECT_NAME=paperless` — and is used by Docker Compose to name the project and prefix the volumes; it is **not** injected into the containers. Writing your `PAPERLESS_*` variables into `.env` produces no error at all: the container starts, the interface responds, and none of your settings are applied. OCR then falls back to English — exactly the trap the next section describes.\n\n```bash\n# Working directory\nmkdir -p \u002Fopt\u002Fpaperless && cd \u002Fopt\u002Fpaperless\n\n# The THREE official files\nBASE=https:\u002F\u002Fraw.githubusercontent.com\u002Fpaperless-ngx\u002Fpaperless-ngx\u002Fmain\u002Fdocker\u002Fcompose\ncurl -fsSL $BASE\u002Fdocker-compose.postgres.yml -o docker-compose.yml\ncurl -fsSL $BASE\u002Fdocker-compose.env          -o docker-compose.env\ncurl -fsSL $BASE\u002F.env                        -o .env\n\n# Generate the key BEFORE writing anything: a QUOTED heredoc (\u003C\u003C'EOF') performs no\n# substitution, the line would be written literally and the \"secret\" would be public.\nSECRET_KEY=$(openssl rand -hex 32)\n\n# The template ships PAPERLESS_SECRET_KEY=change-me: REPLACE it, do not duplicate it.\nsed -i \"s|^PAPERLESS_SECRET_KEY=.*|PAPERLESS_SECRET_KEY=$SECRET_KEY|\" docker-compose.env\n\n# The remaining settings go into the SAME file (unquoted heredoc: $VAR is substituted)\ncat >> docker-compose.env \u003C\u003CEOF\nPAPERLESS_URL=https:\u002F\u002Fpaperless.your-domain.com\nPAPERLESS_TIME_ZONE=Europe\u002FParis\nPAPERLESS_OCR_LANGUAGE=fra+eng+ara\nPAPERLESS_OCR_LANGUAGES=fra ara\nEOF\n\ndocker compose pull\ndocker compose up -d\n```\n\n`PAPERLESS_DBENGINE`, `PAPERLESS_DBHOST` and `PAPERLESS_REDIS` are already set in the `environment:` block of the official compose file: do not redeclare them in `docker-compose.env`. If you write your own compose file, however, `PAPERLESS_DBENGINE=postgresql` is **mandatory** as of v3 (see the migration section): without it, Paperless starts on SQLite.\n\nThe interface is accessible on port 8000 after about 60 seconds of startup, and prompts you to create the administrator account on first access. If you prefer the command line — scripted installation, or recovering access later:\n\n```bash\ndocker compose exec webserver createsuperuser\n```\n\nThen configure your reverse proxy (nginx or Traefik) to expose the service with TLS. If you put one in front of Paperless, read the `PAPERLESS_TRUSTED_PROXIES` paragraph in the migration section: on v3, a misdeclared proxy makes login fail with `403`.",{"type":38,"title":48,"body":49},"Multilingual OCR Configuration","OCR is the core of Paperless-ngx. Its configuration determines the quality of indexing and the ability to find your documents.\n\n**Available Tesseract languages:** the `PAPERLESS_OCR_LANGUAGE` parameter accepts Tesseract language codes separated by `+`. For a French\u002FMoroccan document set:\n\n```bash\nPAPERLESS_OCR_LANGUAGE=fra+ara+eng   # languages used for OCR\nPAPERLESS_OCR_LANGUAGES=fra ara      # Tesseract packages to INSTALL (space-separated)\n```\n\n⚠️ **Both variables are required, and this is the second expensive trap on this page.** `PAPERLESS_OCR_LANGUAGE` defaults to `eng` and only *selects* the language; for any language not present in the image, the documentation requires you to **also** set `PAPERLESS_OCR_LANGUAGES` (a **space**-separated list, not `+`) on Docker deployments. Without it, OCR silently falls back to English: your documents are indexed, but the French and Arabic text is unreadable — and nothing in the interface says so.\n\nThe image already ships English, German, Italian, Spanish and French: only the rest needs installing. Bear in mind too that Tesseract uses considerably more CPU time with several languages enabled — declare only what you actually scan.\n\n**OCR mode:** `PAPERLESS_OCR_MODE` controls when OCR is applied. Four values exist — and `skip`, which is often quoted, is **not** one of them:\n- `auto` (**default**): Paperless checks via `pdftotext` whether the PDF already carries text; if there is enough, OCR is skipped for that document, otherwise it runs normally. This is the safest option for a mixed collection\n- `redo`: re-OCRs every page and attempts to replace existing text layers — useful when the scanner produced poor OCR. It can fail on some documents (forms); the original text is then kept\n- `force`: rasterises the document, turns the text into an image and lays OCR on top. Works everywhere, but the file grows and the text is less sharp when zoomed\n- `off`: never invokes OCR; for PDFs the text is extracted by `pdftotext` alone, and images come out with no text\n\n⚠️ If you are arriving from a 2.x instance, `skip` and `skip_noarchive` **did exist** and were **removed** in v3. A removed value is not silently honoured: Paperless logs a warning at startup and applies the default. v3 splits into two settings what `skip` conflated — when to run OCR (`PAPERLESS_OCR_MODE`) and when to produce the PDF\u002FA archive (`PAPERLESS_ARCHIVE_FILE_GENERATION`, values `auto` by default, `always`, `never`). The migration section gives the mapping table.\n\nFor most use cases, leave `auto`: it avoids reprocessing born-digital PDFs (contracts, software-generated invoices) with nothing for you to tune.",{"type":38,"title":51,"body":52},"Document Date Management: The Problem and the Solution","Automatic date detection is one of Paperless-ngx's most powerful features — and one of the most frustrating when it doesn't work. By default, Paperless-ngx tries to detect the document date from its text content and its filename. Several reasons can lead to an incorrect or missing date.\n\n**Problem 1: The date is in an unrecognised format.** Paperless-ngx detects common formats (`DD\u002FMM\u002FYYYY`, `YYYY-MM-DD`, etc.) but may miss ambiguous ones (`08\u002F09\u002F2025`: 8 September or 9 August?).\n\n**Solution:** verify — rather than \"configure\" — the reading order. `PAPERLESS_DATE_ORDER` **already defaults to `DMY`**, that is day, month, year: setting it explicitly changes nothing and resolves no ambiguity. This setting only serves to **depart** from that default, for example for a collection of US documents:\n```bash\nPAPERLESS_DATE_ORDER=MDY  # MM\u002FDD\u002FYYYY — only set this if your documents are dated that way\n```\nFor a mixed collection, no global order can be correct: it is the file naming (problem 3 below) that decides.\n\n**Problem 2: The document has multiple dates and the wrong one is chosen.** For example, an invoice that mentions the service date AND the issue date — Paperless-ngx takes the first one found.\n\n**Solution:** use the manual date field in the web interface to fix badly dated documents, or configure matching rules that assign a date from the filename.\n\n**Problem 3: The file creation date is used instead.** When no date is found in the content, Paperless-ngx falls back to the file modification date — which can be very misleading for old documents scanned recently.\n\n**Solution:** name import files with the document date (`YYYY-MM-DD_document-name.pdf`) — Paperless-ngx detects this format in the filename before analysing the content.",{"type":38,"title":54,"body":55},"Resolving Timeouts on Entry-Level VPS","On a VPS with 1 or 2 vCPU, OCR processing of large documents can exceed the default timeout and leave the document stuck in \"Pending processing\" status indefinitely.\n\n**Diagnosis:** check the worker logs:\n```bash\ndocker compose logs celery --tail=50\n```\n`SoftTimeLimitExceeded` lines confirm a timeout.\n\n**Resolution — four levers:**\n\n**1. Increase the task timeout:**\n```bash\nPAPERLESS_WORKER_TIMEOUT=3600  # 1 hour (default: 1800 s)\n```\n⚠️ The exact name matters: `PAPERLESS_WORKER_TIMEOUT`. A misspelled setting is not rejected by Paperless — it is **silently ignored**, and the timeouts continue exactly as before, which reads wrongly as \"the fix didn't work\".\n\n**2. Reduce import resolution.** If you scan documents yourself, 200 DPI is sufficient for quality OCR — 300 DPI doubles processing time with no perceptible improvement for standard text.\n\n**3. Limit parallel processing:**\n```bash\nPAPERLESS_TASK_WORKERS=1        # tasks in parallel (default: 1)\nPAPERLESS_THREADS_PER_WORKER=1  # pages processed in parallel within ONE document\n```\nWhen unset, `PAPERLESS_THREADS_PER_WORKER` is `max(floor(core_count \u002F PAPERLESS_TASK_WORKERS), 1)`. The upstream rule not to cross: the **product** `TASK_WORKERS × THREADS_PER_WORKER` must not exceed the number of cores, or the instance becomes extremely slow. Many workers = many documents in parallel; many threads = one large document processed faster.\nOn a 2 vCPU VPS, processing two documents at once can cause timeouts that the same volume handled sequentially would avoid.\n\n**4. Optimise PDF preprocessing:**\n```bash\nPAPERLESS_OCR_USER_ARGS={\"optimize\": 1, \"pdfa-image-compression\": \"jpeg\"}\n```\nThis compresses images inside PDFs before processing, reducing memory and CPU load.",{"type":38,"title":57,"body":58},"Upgrading from 2.x to 3.x","The 3.x series of Paperless-ngx brings structural changes that make in-place migration mandatory, and adds prerequisites that did not exist on the 2.x branch.\n\n**The prerequisite everyone forgets:** upgrading to v3 is supported **only from 2.20.15**. If you are running an older version, move to 2.20.15 first, and only then to 3.x. Switching the image tag directly from a 2.14 to a 3.x is not a supported path, and nothing will warn you at startup.\n\nExport\u002Fimport between versions (`document_exporter` then `document_importer` on a fresh instance) is **not supported** — and the upstream rule is broader than commonly believed: it holds between **any two versions**, not just across majors, because an export contains an exact image of the database. In practice, `document_importer` warns (`Version mismatch: Currently 3.1.x, importing 2.20.15. Continuing, but import may fail.`) then fails on `KeyError: 'show_on_dashboard'` — a `SavedView` model field that existed in 2.20.15 and no longer exists in the 3.x schema. The only safe path is to let the migrations apply to the existing database.\n\n**Recommended procedure:**\n\n1. Take a full backup before anything else (see the dedicated section below).\n2. Stop the services: `docker compose down`.\n3. Review, in `docker-compose.env` and `docker-compose.yml`, the settings that v3 makes mandatory or removes (detailed just below).\n4. Point the `docker-compose.yml` image at the target 3.x version and restart: `docker compose up -d` — Django migrations apply automatically at `webserver` startup.\n5. Monitor the logs: `docker compose logs webserver --tail=100` — a failing migration prints the error and blocks startup.\n\n**`PAPERLESS_SECRET_KEY` becomes mandatory.** There used to be a built-in default key; on v3 it must be declared, and Paperless refuses to start without it. Reusing the previous value preserves sessions and signed tokens; setting a new one invalidates them all. That is a deliberate choice, not a configuration detail.\n\n**`PAPERLESS_DBENGINE` becomes mandatory with PostgreSQL or MariaDB.** On v2 the engine was **inferred** from the presence of `PAPERLESS_DBHOST`; on v3 it must be explicit, and the default value is `sqlite`. The accepted values are `sqlite`, `postgresql` and `mariadb` — nothing else. This is the first migration trap: without this setting, the instance starts on an empty SQLite database, your PostgreSQL is intact but nobody reads it any more, and the dashboard reports zero documents.\n```yaml\n# v2 (PostgreSQL inferred from PAPERLESS_DBHOST)\nPAPERLESS_DBHOST: db\n# v3 (the engine must be explicit)\nPAPERLESS_DBENGINE: postgresql\nPAPERLESS_DBHOST: db\n```\n\n**`PAPERLESS_OCR_MODE=skip` is gone.** The `skip` and `skip_noarchive` values have been removed, and a removed variable is not silently honoured: a warning is logged at startup. Preserving v2 behaviour means splitting the intent across two now-independent settings:\n```bash\n# v2: skip OCR when text is present, but always archive\nPAPERLESS_OCR_MODE=skip\n# v3: equivalent\nPAPERLESS_OCR_MODE=auto\nPAPERLESS_ARCHIVE_FILE_GENERATION=always\n```\n\n**Redis → Valkey incompatibility.** As of v3, the **official** compose file ships **Valkey** as the broker (`valkey\u002Fvalkey:9-alpine`), no longer Redis: this is not a fringe choice, it is what you get as soon as you replace your compose file with the project template. If your broker volume was created by a recent Redis version, Valkey refuses to load it and the container enters a restart loop on `Can't handle RDB format version 15` (or `13`, depending on the origin), while the `webserver` waits for a broker that never comes. The fix is to **delete the broker volume** before switching: it only holds queued tasks, no critical persistent data.\n```bash\ndocker compose down\ndocker volume rm paperless_redisdata   # the prefix comes from COMPOSE_PROJECT_NAME\ndocker compose up -d\n```\n\n**The search index rebuilds itself.** v3 replaces Whoosh with Tantivy, and the format is incompatible: the index is rebuilt from scratch on first startup — which explains a slower first launch. Under Docker the container runs `document_index reindex --if-needed` on every start, so no manual action is required. If consumption nonetheless fails with `Schema error: 'An index exists but the schema does not match.'` (a case reported on an instance that had run the 3.0 beta), force a clean rebuild:\n```bash\ndocker compose exec webserver document_index reindex --recreate\n```\nWatch the search syntax too: `note:` becomes `notes.note:` and `custom_field:` becomes `custom_fields.value:`. Saved views carrying an explicit prefix are migrated automatically, but a search **without** a prefix that used to match note content will no longer do so.\n\n**Three behaviour changes that catch people out.** Task history is **cleared** during the upgrade: past, failed or acknowledged tasks will not reappear. v3 no longer **rejects duplicates** by default — it accepts them and lets you spot them in the interface; if you relied on that rejection, re-enable it with `PAPERLESS_CONSUMER_DELETE_DUPLICATES=true`. Finally, behind a reverse proxy, login rate limiting now determines the client IP differently: if login returns `403 Forbidden` after the upgrade, declare the chain with `PAPERLESS_TRUSTED_PROXIES`, and if needed `PAPERLESS_ALLAUTH_TRUSTED_PROXY_COUNT` — the number of hops in `X-Forwarded-For`, which is not necessarily the number of configured IP addresses.\n\n**About MariaDB.** It remains supported (`PAPERLESS_DBENGINE=mariadb`), even though the project recommends PostgreSQL for new installations. The Debian 12 migration failures circulating on forums did not come from the driver: they came from **bare-metal** installations where the new release had been unpacked on top of the old one. Stale migration files left on disk make `manage.py migrate` fail with a `NodeNotFoundError`. The remedy is to delete the previous source tree (`src\u002F`, `static\u002F`) before deploying, not to change database engine — and in a Docker deployment like the one in this guide, that scenario cannot occur, since the image is replaced wholesale.\n\n**Mail after the upgrade.** The command that forces a mail fetch is `mail_fetcher`, with no argument: it processes every configured account and rule.\n```bash\ndocker compose exec webserver mail_fetcher\n```\nIf a mail flow stops producing documents after the upgrade, look at the task error in the interface first: the reported cases pointed to the search index (the `Schema error` above), not to credentials. Then check that the account still holds its IMAP permissions; if you use an OAuth token, tick the box indicating that the password is in fact a token.",{"type":60,"body":61},"tip","Before any major update, test the procedure on a copy of your environment. With Docker Compose, this means copying your `\u002Fopt\u002Fpaperless` directory to a second VPS, pointing a test subdomain, and applying the update there. You can then verify that your documents, tags and correspondents are intact before touching production.",{"type":38,"title":63,"body":64},"Automatic Backup of Paperless-ngx","Paperless-ngx manages two types of critical data: the PostgreSQL database (metadata, tags, correspondents, rules) and the document files. Both must be backed up — one without the other restores nothing usable.\n\n**Daily backup script:**\n```bash\n#!\u002Fbin\u002Fbash\nBACKUP_DIR=\"\u002Fbackups\u002Fpaperless\u002F$(date +%Y%m%d)\"\nmkdir -p \"$BACKUP_DIR\"\n\n# PostgreSQL dump\ndocker compose exec -T db pg_dump -U paperless paperless \\\n  | gzip > \"$BACKUP_DIR\u002Fdb.sql.gz\"\n\n# Native Paperless export (includes config and documents)\ndocker compose exec -T webserver document_exporter ..\u002Fexport\ntar -czf \"$BACKUP_DIR\u002Fexport.tar.gz\" \u002Fopt\u002Fpaperless\u002Fexport\u002F\n\n# Rotation — keep 14 days\nfind \u002Fbackups\u002Fpaperless -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +\n\necho \"Backup complete: $BACKUP_DIR\"\n```\n\nSchedule this script in cron (`0 3 * * *` for 3am), and verify that backups reach storage external to the VPS (rsync to an S3 bucket or another server). The `-T` after `exec` avoids the \"the input device is not a TTY\" error when the script runs without a terminal.\n\n⚠️ An export does not replace a volume backup, and is not a bridge between versions: it can only be re-imported into **the same version** of Paperless-ngx that produced it. For disaster recovery, therefore, also keep a copy of the Docker volumes, or record the exact version alongside the export.",{"type":38,"title":66,"body":67},"Updates and Maintenance","Paperless-ngx publishes regular releases. Updating is straightforward with Docker Compose:\n\n```bash\n# Pull the new image\ndocker compose pull\n\n# Restart the services (database migrations apply automatically)\ndocker compose up -d\n\n# Check everything is OK\ndocker compose logs webserver --tail=20\n```\n\n**Before each major update:** read the CHANGELOG on GitHub — major versions (v2.x → v3.x) may require additional migration steps, and sometimes a **mandatory intermediate version**, such as 2.20.15 before v3. The dedicated section above details the known incompatibilities of the 3.x series.\n\n**Monitoring:** Paperless-ngx does **not** expose a `\u002Fmetrics` endpoint of its own. What exists is **Flower**, the Celery task monitor, enabled by defining `PAPERLESS_ENABLE_FLOWER`; it is Flower that exports metrics usable by Prometheus, on top of showing tasks in progress, queued and completed. This is the right place to spot a processing job that stops silently — the symptom of an OCR timeout, precisely.\n\n⚠️ One detail that changes after moving to v3: since task history was cleared by the migration, an empty list on first startup is not a sign of failure. It is the tasks **after** the upgrade that count.","Digitise and index all your documents","ServOrbit VPS Cloud provides the CPU, storage and Docker environment ready for Paperless-ngx, its Tesseract OCR, PostgreSQL and Redis. Turn your paper stacks into a searchable, backed-up archive under your sole control.","Deploy Paperless-ngx on a Cloud VPS","\u002Fvps-cloud",[73,92,110],{"id":74,"slug":75,"slugs":76,"title":80,"excerpt":81,"readTime":82,"views":83,"isPinned":19,"noindex":19,"publishedAt":84,"updatedAt":85,"category":86,"categories":87,"featuredImage":30,"bgImage":31,"posterImage":89,"relatedSolution":90},71,"hosting-nextcloud-on-your-own-vps",{"fr":77,"en":75,"ar":78,"es":79},"heberger-nextcloud","استضافة-nextcloud-على-خادمك-الـvps-الخاص","alojar-nextcloud-en-su-propio-vps","Self-Host Nextcloud on VPS: NC 35, PHP 8.3 and MariaDB 11 Guide","Host Nextcloud on a VPS: Docker Compose, Redis, MariaDB backup, uploads over 40 GB behind Cloudflare and an alternative to Office 2021.",20,1,"2026-04-10T00:00:00+00:00","2026-11-08T16:32:50+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[88],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-nextcloud-poster.svg",{"categorySlug":25,"appSlug":91},"nextcloud",{"id":93,"slug":94,"slugs":95,"title":99,"excerpt":100,"readTime":101,"views":83,"isPinned":19,"noindex":19,"publishedAt":102,"updatedAt":103,"category":104,"categories":105,"featuredImage":30,"bgImage":31,"posterImage":107,"relatedSolution":108},72,"hosting-ghost-on-your-own-vps",{"fr":96,"en":94,"ar":97,"es":98},"heberger-ghost","استضافة-ghost-على-خادمك-الـvps-الخاص","alojar-ghost-en-un-vps","Hosting Ghost on your own VPS: complete 2026 guide","Deploy Ghost v6 on your VPS with Caddy, MySQL, Ghost CLI and Stripe Tax: installation, TLS reverse proxy, updates and troubleshooting common startup errors.",10,"2026-04-09T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[106],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-ghost-poster.svg",{"categorySlug":25,"appSlug":109},"ghost",{"id":111,"slug":112,"slugs":113,"title":117,"excerpt":118,"readTime":23,"views":119,"isPinned":19,"noindex":19,"publishedAt":120,"updatedAt":121,"category":122,"categories":123,"featuredImage":30,"bgImage":31,"posterImage":125,"relatedSolution":126},73,"host-wordpress-on-your-own-vps",{"fr":114,"en":112,"ar":115,"es":116},"heberger-wordpress","استضافة-wordpress-على-خادم-vps-الخاص-بك","alojar-wordpress-en-un-vps","Host WordPress on your own VPS","Host WordPress on your VPS for maximum performance and control: Docker, MariaDB, caching, reverse proxy and SSL.",0,"2026-04-08T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[124],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-wordpress-poster.svg",{"categorySlug":25,"appSlug":127},"wordpress",true,1794270414048]