How to Host a Jekyll Site on Droply

Jekyll is still one of the fastest ways to build a blog, docs site, or portfolio: write Markdown, run one command, get a folder of plain HTML. The tricky part has always been the last step — getting that folder onto the public internet without wrestling with a git remote, a build pipeline, or a server. This guide shows you how to host a Jekyll site on Droply by treating it as what it really is: a bundle of static files that just need a home.

Why Droply is a good fit for Jekyll

Jekyll produces a fully pre-built _site directory. There is no runtime, no database, no server-side rendering. That output is exactly what Droply is designed to serve: static HTML, CSS, JS, images, and assets, delivered over HTTPS at a URL like yoursite.droply.id.

Because Droply does not run builds on its side, you keep full control of your Jekyll version, plugins, and theme. You build locally (or in whatever CI you already trust), and Droply just hosts the result. That means:

Any Jekyll plugin works, including non-whitelisted ones that GitHub Pages blocks.
Any Ruby or Jekyll version works — Droply never touches your Gemfile.
Re-uploads replace the content in place, so the URL stays the same forever.

If you have ever wanted to host a Jekyll site without adopting a git-based deploy workflow, this is the shortest path.

What you need before you start

Before deploying, make sure you can build the site locally:

Ruby installed (via rbenv, asdf, or your OS package manager).
Bundler: gem install bundler.
Your Jekyll project with a working Gemfile and _config.yml.

Test that it builds cleanly:

bundle install
bundle exec jekyll build

If that command succeeds, you have a _site/ folder ready to ship.

Step 1: Configure your site for production

Before the final build, check two things in _config.yml.

Set the correct URL

If you plan to serve the site at myblog.droply.id, set:

url: "https://myblog.droply.id"
baseurl: ""

If you plan to move to a custom domain later on a paid plan, you can update url at that point and rebuild.

Use root-relative asset paths

In your templates, prefer {{ '/assets/style.css' | relative_url }} over hard-coded paths. This keeps links portable if you ever change domains or preview the build locally.

Step 2: Build the production bundle

Run a clean production build:

JEKYLL_ENV=production bundle exec jekyll build

The JEKYLL_ENV=production flag matters — it enables analytics snippets, minification in some themes, and disables development-only output. When it finishes, everything you need is inside _site/.

Quickly sanity-check it by serving it locally with any static server:

cd _site
python3 -m http.server 8000

Open http://localhost:8000 and click through a few pages. If it looks right here, it will look right on Droply.

Step 3: Zip the _site folder

Droply accepts a ZIP of your static site. From inside your project root:

cd _site
zip -r ../site.zip .

The important detail: zip the contents of _site, not the _site folder itself. Your index.html should sit at the top level of the archive. If you accidentally zip the parent folder, your site will end up at yoursite.droply.id/_site/ instead of the root.

You can verify with:

unzip -l site.zip | head

You should see index.html, assets/, and your other top-level files listed at the root.

Step 4: Upload to Droply

Now the fast part. On droply.host:

Drag site.zip onto the upload area.
Pick a name — this becomes the subdomain, e.g. myblog for myblog.droply.id.
Wait a few seconds while Droply extracts and serves it.

That is the entire deploy. No git push, no build minutes, no environment variables. You get a live HTTPS URL immediately.

Step 5: Update the site later

Every time you publish a new post or tweak a template, the workflow is the same:

JEKYLL_ENV=production bundle exec jekyll build
cd _site
zip -r ../site.zip .

Then re-upload site.zip to the same Droply site. The content is replaced in place and the URL stays identical, so any links you have shared keep working. This makes it safe to iterate — you can push a change, share the link, get feedback, and push again five minutes later.

Handling common Jekyll gotchas

A few things trip people up when they host a Jekyll site as a static bundle.

404s on "pretty" URLs

Jekyll generates about/index.html for a page called about.md with permalink: /about/. This works fine on Droply — the trailing-slash URL resolves to the folder's index.html. But if you have permalink: /about (no trailing slash), Jekyll may output about.html instead. Pick one convention and stick with it.

Missing assets

If images or stylesheets 404, it is almost always because of a hard-coded baseurl or an absolute path pointing at localhost:4000. Rebuild with the correct url and baseurl values in _config.yml and re-upload.

Draft posts showing up

Only posts in _posts/ with a valid date are built by default. Anything in _drafts/ stays out unless you pass --drafts. A clean production build should never leak drafts.

Beyond blogs: other static things worth hosting

Once you have this workflow, Droply becomes useful for a lot more than Jekyll. The same drag-and-drop flow works for:

A single HTML file — a landing page, a coming-soon page, or a signed proposal.
A PDF — a case study, a spec sheet, or an invoice you want to link to.
A design prototype exported from Figma, Framer, or Webflow as static HTML.
Any static-site generator's output: Hugo's public/, Astro's dist/, Eleventy's _site/, or a hand-written folder.

The point is that anything you can pre-build, you can ship in seconds without adopting a full deploy pipeline.

When to upgrade

The free tier is enough to host a Jekyll site and share it publicly. When you want your own domain instead of a droply.id subdomain, or when you want to remove the "powered by" banner for a client project, that is when a paid plan makes sense. Details are on the pricing section.

Wrap-up

To host a Jekyll site on Droply, you build locally with JEKYLL_ENV=production bundle exec jekyll build, zip the contents of _site/, and drop the archive onto Droply. That is the whole workflow. No CI, no server, no plugin allowlist — just the static output Jekyll was designed to produce, served at a URL you can share the moment it finishes uploading.