Files
bentopdf/STATIC-HOSTING.md
T

9.0 KiB

Hosting BentoPDF as a static website

As an alternative to running BentoPDF locally or in a Docker container, you can easily host it as a set of static web pages. Here are a few examples:

Netlify

Netlify - static deployment

One of the simplest ways to host BentoPDF is to create a project at Netlify and create a static deployment. You can accomplish this by first downloading the pre-built distribution file from our GitHub releases. Each release includes a dist-{version}.zip file that contains all necessary files for self-hosting.

  1. Go to BentoPDF Releases
  2. Download the latest dist-{version}.zip file
  3. Next, if you have not already done so, create a Netlify account and log in.
  4. From your Netlify projects page, add a new project and select "Deploy manually".
  5. Drag and drop to upload the BentoPDF zip file you downloaded in step 2.
  6. Your BentoPDF deployment should now be working! Optionally, you can go into Project Configuration and change the project name.

When a new BentoPDF release becomes available, you will need to repeat steps 1-3, then go into "Deploys" and upload the new release.

Netlify - dynamic deployment

Alternatively, you can configure a Netlify project to automatically deploy whenever your BentoPDF is updated.

  1. If you have not done so already, create a fork of BentoPDF into your own GitHub account.
  2. If you have not already done so, create a Netlify account and log in.
  3. From your Netlify projects page, add a new project and select 'Import an existing project'.
  4. Select the GitHub button, authorize Netlify, then choose where to install the integration. You can choose 'All repositories' or 'Only select repositories' and choose your BentoPDF fork.
  5. Select your repo and give it a project name. (add environment variables?) Then click the blue 'Deploy' button.
  6. The Netlify build & deploy process will kick off. Once it finishes, you can click on the provided URL https://[projectname]/netlify.app to view your deployment of BentoPDF.

Whenever the BentoPDF source code is updated, you can sync the changes into your repo. This will kick off a new build and deploy within Netlify.

If you want to use BentoPDF's simple mode, go into Deploy Settings, then Environment Variables, and Add a variable. Add SIMPLE_MODE and set it to true. You will need to manually kick a new build to get this to take effect.

Vercel

Vercel provides similar services to Netlify dynamic hosting.

  1. If you have not done so already, create a fork of BentoPDF into your own GitHub account.
  2. If you have not already done so, create a Vercel account and log in.
  3. From your Vercel Overview page, select 'Add new project'
  4. Under 'Import Git Repository' and then choose 'Add GitHub Account'. Follow the prompts to authorize Vercel integration. You can choose 'All repositories' or 'Only select repositories' and choose your BentoPDF fork.
  5. Select 'Import' to import the repo into Vercel.
  6. Under 'Framework Preset', select 'Vite' and save the settings.
  7. The Vercel build & deploy process will kick off. Once it finishes, you can click on the provided link to view your deployment of BentoPDF.

Whenever the BentoPDF source code is updated, you can sync the changes into your repo. This will kick off a new build and deploy within Vercel.

If you want to use BentoPDF's simple mode, go into Project Settings, then Environment Variables, and Create a new variable. Add SIMPLE_MODE and set it to true. You will need to redeploy to get this to take effect.

GitHub Pages

You can also host your own instance of BentoPDF using GitHub Pages. An advantage of this over the other options is you are able to do everything in GitHub without any third-party service.

  1. If you have not done so already, create a fork of BentoPDF into your own GitHub account.
  2. From your fork, go to Settings->Pages, and change the 'Source' to 'GitHub Actions'
  3. Go to Settings->Secrets and Variables > Actions, then select 'Variables', and add the repository variable BASE_URL. Set the value to /bentopdf. If you've renamed the repo to something other than bentopdf, put that here.
  4. Go to Actions in the top menu, and select 'I understand' to enable Actions
  5. Within Actions, on the left, select 'Deploy static content to Pages', and then on the right select 'Run workflow', and in the dropdown, 'Run Workflow'. The action will now run to build BentoPDF and deploy it to GitHub Pages.

When the build completes, you can find the website at https://[your-github-username]/bentopdf

If/when you merge changes from the source BentoPDF repository, the build and deploy action will automatically be kicked off and the new version will be automatically deployed to GitHub Pages.

Note: GitHub Pages cannot set custom response headers, so a GitHub Pages deployment is served without BentoPDF's Content-Security-Policy and other security headers. If you need them, use one of the other hosts below or put a proxy or CDN that can add headers in front of your Pages site.

Security headers

BentoPDF ships a Content-Security-Policy and other security headers for each static host:

  • Netlify and Cloudflare Pages read _headers from the deployed folder. npm run build writes dist/_headers with scripts/generate-security-headers.mjs, so any VITE_WASM_*, VITE_TESSERACT_*, VITE_CORS_PROXY_URL or VITE_OCR_FONT_BASE_URL values you set at build time are allowed by the policy. If you add your own public/_headers, the build ships yours instead. The release dist-{version}.zip already contains it.
  • Vercel uses the headers block in vercel.json. It holds the default policy, so if you point the VITE_* URLs at your own servers, update the Content-Security-Policy there to match the dist/_headers your build produces.
  • npx serve reads serve.json from the folder it serves. To use the repository's serve.json with the build output, run npx serve dist -c ../serve.json.
  • GitHub Pages cannot set headers (see the note above).

SEO and search engine indexing

By default, every self-hosted BentoPDF build emits canonical URLs and an hreflang/x-default set that point back to https://www.bentopdf.com. This is intentional for two reasons:

  1. It consolidates SEO signals to the official site so your instance doesn't compete with bentopdf.com on brand searches like "bentopdf".
  2. It keeps your instance off public search results. If you self-host on a small VPS, a home server, or anywhere with limited bandwidth, you probably don't want strangers from Google landing on it. With the default canonical pointing back to the official site, search engines treat your instance as a copy and won't surface it for organic traffic and your bandwidth is reserved for the people you actually share the URL with.

You have two clean overrides depending on what you want.

Run your own SEO instance (claim canonical for yourself)

If you operate a public deployment and want it to be the indexed copy for your audience, set SITE_URL at build time to your origin and also set ALLOW_INDEXING=true. The build will emit canonicals, hreflang and sitemap URLs pointing at your domain. Without ALLOW_INDEXING=true, a build with a custom SITE_URL marks every page noindex.

  • Docker:
    docker build --build-arg SITE_URL=https://pdf.example.com --build-arg ALLOW_INDEXING=true -t bentopdf-self .
    
  • Netlify, Vercel, GitHub Pages, or any other static host: set SITE_URL and ALLOW_INDEXING=true in your project's environment variables and re-deploy. The build script reads them during npm run build. For the GitHub Pages workflow, add both as repository variables.

Stay invisible to search engines (no SEO competition either way)

Set the runtime environment variable ROBOTS_NOINDEX=true. The container then sends an X-Robots-Tag: noindex, follow header with every response. The canonical link still points at the official site by default, so when crawlers do follow internal links they still see bentopdf.com as the authoritative source. ROBOTS_NOINDEX only works in the Docker image; if you serve the files yourself, build with your own SITE_URL instead (see above).

docker run -d -p 8080:8080 -e ROBOTS_NOINDEX=true ghcr.io/alam00000/bentopdf:latest

A build with your own SITE_URL and without ALLOW_INDEXING=true is already noindex, so it neither competes with bentopdf.com nor advertises itself. ROBOTS_NOINDEX=true does the same at runtime for the prebuilt images.

Note on Simple Mode

Simple Mode (SIMPLE_MODE=true) controls the UI — it ships a stripped-down homepage suitable for company intranets and single-purpose deployments. It does not by itself control whether your instance is indexed by search engines. A public-facing simple-mode deployment is fully indexable by default, just like the full-mode build. If you want a simple-mode deployment hidden from search engines, combine SIMPLE_MODE=true at build time with ROBOTS_NOINDEX=true at runtime.