How to publish a static folder on a VPS with Caddy

How to publish a static folder on a VPS with Caddy

By Revdoku Content TeamUpdated
Table of Contents

A VPS gives you full control over hosting. This tutorial shows the simple version: create a server, install Caddy, copy a static folder to the server, point a domain at it, and let Caddy serve it with HTTPS.

This is a useful workflow when you want to own the infrastructure. It is also a good contrast with Revdoku, where the same kind of folder can be published without operating a server.

What you need

Start with a static folder:

static-site/
  index.html
  styles.css
  app.js
  Readme.md
  data/report.csv
  docs/brief.pdf
  assets/chart.webp

You also need:

  • A VPS from AWS Lightsail, Hetzner, DigitalOcean, or another provider.
  • SSH access.
  • A domain or subdomain if you want HTTPS on a real hostname.
  • Basic comfort with the command line.

Creating a Linux instance in AWS Lightsail

Choosing an AWS Lightsail instance plan

Choosing a local static folder before publishing

1. Create a VPS

Create a small Linux server with your provider.

Ubuntu LTS is a common choice. Add your SSH key during server creation if the provider supports it.

After the server is created, note:

  • Public IP address.
  • Username.
  • SSH key.
  • Provider firewall settings.

Open ports 80 and 443 for HTTP and HTTPS.

2. Point your domain at the server

In your DNS provider, create an A record:

site.example.com -> YOUR_SERVER_IP

Wait for DNS to propagate. You can test with:

dig site.example.com

If you do not have a domain, you can test over the server IP, but HTTPS with a trusted certificate is simpler when you have a real hostname.

3. SSH into the server

Connect to the server:

ssh root@YOUR_SERVER_IP

Some providers use a different default username such as ubuntu. Use the username shown by your provider.

4. Install Caddy

Caddy is a good choice for simple static hosting because it can manage HTTPS certificates automatically for real domains.

On Ubuntu, install Caddy using the official Caddy installation instructions for your current distribution.

After installation, confirm it runs:

caddy version
systemctl status caddy

5. Create the site folder

Create a folder for the site:

mkdir -p /var/www/static-site

Copy your generated files into that folder.

From your local machine, one common approach is:

rsync -av ./static-site/ root@YOUR_SERVER_IP:/var/www/static-site/

The trailing slash matters: it copies the contents of static-site into the target folder.

6. Configure Caddy

Edit the Caddyfile:

nano /etc/caddy/Caddyfile

Use a simple static configuration:

site.example.com {
  root * /var/www/static-site
  file_server
}

Save the file, then reload Caddy:

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

When DNS is correct and ports are open, Caddy will request and manage the HTTPS certificate automatically.

7. Test the live site

Open:

https://site.example.com

Check:

  • The homepage loads.
  • Assets load.
  • Internal links work.
  • Large files download or render as expected.
  • No private drafts are accidentally in the folder.
  • HTTPS is active.

8. Update the site later

To update the site, copy new files to /var/www/static-site.

For example:

rsync -av ./static-site/ root@YOUR_SERVER_IP:/var/www/static-site/

If the Caddy configuration did not change, no reload is usually needed for static files.

9. Add password protection if needed

Caddy can support basic authentication with extra configuration. You will need to generate a hashed password and update the Caddyfile.

That works, but it is now server configuration. You will also need to decide how to share passwords, rotate them, remove access, and log visits.

For some teams, that control is useful. For many client-review folders, it is extra work.

10. Add analytics if needed

A VPS does not automatically give you product-style website analytics.

You can add analytics by:

  • Installing a JavaScript analytics tool.
  • Running a self-hosted analytics service.
  • Parsing web server logs.
  • Sending logs to an external service.

Again, this can be powerful, but it means owning more infrastructure.

When VPS hosting is the right choice

Use a VPS when:

  • You need backend code.
  • You need a database.
  • You need Docker.
  • You need custom server software.
  • You want root control.
  • You are comfortable with DNS, TLS, SSH, security, logs, backups, and updates.

When Revdoku is simpler

Use Revdoku when:

  • The output is a static folder or file bundle.
  • You want a live URL without setting up a server.
  • You need public, password, or password plus email access.
  • You want built-in viewers for Markdown, HTML, CSV, PDF, and other common files.
  • You want analytics after sharing.
  • You want AI tools such as Claude, Codex, ChatGPT, or local scripts to publish updates into the same workspace.

With Revdoku, the workflow is:

  1. Upload or publish the folder to a Revdoku bucket.
  2. Publish the bucket as a website.
  3. Choose the access mode.
  4. Share the URL.
  5. Review analytics.

The same folder published with Revdoku navigation

Revdoku password setting for the same static folder

Revdoku analytics for the shared static folder

Takeaway

A VPS is the right choice when you need to operate a server.

Revdoku is the right choice when you need to publish a folder.

The Caddy workflow is not difficult for developers, but it is still infrastructure. For AI-generated folders, client reports, static prototypes, and mixed file bundles, Revdoku removes the server work and keeps the URL, files, access controls, and analytics in one place.

Keep reading

Sources checked

Start publishing for free

Share:
Markdown version

Related Articles

↧
Loading PDF…