1. Home
  2. Blog
  3. Self-hosting

How to Self-Host a Markdown Editor on Shared Hosting, Docker or nginx

Host your own Markdown editor with live preview in minutes. Step-by-step instructions for shared hosting (cPanel), Docker, nginx and Caddy — no database or backend required.

A self-hosted Markdown editor gives your team a single, familiar tool on your own domain — no accounts, no subscriptions and no dependency on someone else’s service staying online. If the editor is a static web app, hosting it is as simple as hosting a few HTML files: there is no database to maintain, no server-side code to update and almost no load on the server.

The examples below use Markdown Preview Editor. It’s free and open source (MIT), and the same steps apply to any static web application.

Why self-host a Markdown editor?

  • Your domain, your rules. The editor is available at an address you control, for example markdown.your-company.com, and it works the same for everyone who uses it.
  • Nothing to maintain. A static site has no backend, so there are no security patches for server code and no database backups.
  • Documents stay local. Markdown Preview Editor renders everything in the visitor’s browser. The server only delivers the app’s files — it never receives the documents.
  • It’s free to run. Any shared hosting plan, a small VPS or a container platform is enough.

What you need

Any web server that can serve static files over HTTPS:

  • shared hosting with cPanel, Plesk or DirectAdmin (Apache or LiteSpeed),
  • a server with Docker,
  • nginx or Caddy on a VPS,
  • or even your own computer for local use.

No PHP, Node.js or database is needed on the server.

Option 1: Shared hosting (cPanel and similar)

This is the quickest route, and you won’t need a command line.

  1. Download the site archive. Grab markdown-preview-editor-site.zip from the latest release. It contains the ready-built website.
  2. Choose the address. Use your main domain, or create a subdomain such as markdown.example.com in the hosting control panel. Note the subdomain’s document root folder.
  3. Enable HTTPS. Most hosts issue free certificates automatically (AutoSSL or Let’s Encrypt). Make sure the certificate is active for the domain or subdomain.
  4. Upload and extract. Open the File Manager, go to the document root, upload the zip file and choose Extract. The files — including a hidden .htaccess — must be directly in the document root, not in a subfolder.
  5. Open your domain. The editor is ready.

The bundled .htaccess redirects HTTP to HTTPS, sets security headers and configures caching on Apache and LiteSpeed servers.

Tip

If your host’s upload scanner rejects zip archives that contain JavaScript files — a known false positive with some antivirus rules — use the .tar.gz archive from the same release or upload the files over FTP.

Option 2: Docker

If you run containers, clone the repository and start the included Compose file:

bashgit clone https://github.com/ovasendin/markdown_preview_editor.git
cd markdown_preview_editor
PORT=8080 docker compose -f deploy/docker-compose.yml up -d --build

Open http://localhost:8080 — or whichever port you chose. The image builds the site and serves it with nginx and the same security headers. For a public domain, put the container behind your usual reverse proxy with HTTPS.

Option 3: nginx

Build the site (or extract the release archive) and copy the files to your web root:

bashnpm ci && npm run build
sudo cp -r dist/* /var/www/markdown/

The repository contains a ready configuration in deploy/nginx.conf with the security headers and caching rules. The core of a static site configuration is short:

nginxserver {
    listen 443 ssl;
    server_name markdown.example.com;
    # ssl_certificate and ssl_certificate_key lines go here

    root /var/www/markdown;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Reload nginx with sudo nginx -s reload and open the domain.

Option 4: Caddy

Caddy gets HTTPS certificates on its own, so on a VPS it is the simplest option:

bashSITE_ADDRESS=markdown.example.com caddy run --config deploy/Caddyfile

Copy the built files to /srv first; the included Caddyfile serves them with the same headers as the other options.

Option 5: Run it locally

For personal use, no server is needed at all:

bashnpm ci
npm run dev

Open the printed local address in your browser.

Keeping it up to date

Updating a static site means replacing its files. Download the new release archive, extract it over the old files and reload the page. Because the app’s file names include content hashes, browsers pick up the new version without stale caches. Watch the GitHub repository (Watch → Custom → Releases) to get notified about new versions.

A checklist after deployment

  • The site opens over https:// and http:// redirects to it.
  • Drag a Markdown file onto the editor — it opens in a new tab.
  • Switch the theme and the language in the settings.
  • Export a test document to HTML to confirm downloads work.

Once your editor is live, share the Markdown cheat sheet with your team, and bookmark our guides on previewing Markdown and exporting to HTML and PDF.

Frequently asked questions

Can I host a Markdown editor on shared hosting?

Yes. A static Markdown editor such as Markdown Preview Editor is just HTML, CSS and JavaScript files. Upload and extract the release archive into the document root of your domain or subdomain — no database or server-side language is required.

Does the self-hosted editor send documents to my server?

No. The server only delivers the application files. Documents are opened and rendered in each visitor’s browser and are not uploaded.

Can I host it in a subfolder instead of a subdomain?

Yes, the app works from a subfolder such as example.com/markdown/. A separate subdomain is recommended, though, because it isolates the editor’s browser storage from other apps on the same domain.

How much server resources does it need?

Almost none. The server only sends static files once per visitor; afterwards they are cached by the browser. All the work happens on the visitor’s device.