Awesome

Indie Web Server

Indie Web Server is a secure and seamless Small Tech personal web server for Linux and Linux-like* operating systems.

• Zero-configuration – It Just Works 🤞™.

• Develop with automatically-provisioned locally-trusted TLS courtesy of mkcert seamlessly integrated via Nodecert.

• Test and deploy with automatically-provisioned globally-trusted TLS courtesy of Let’s Encrypt seamlessly integrated via ACME TLS and systemd. Your server will score an A on the SSL Labs SSL Server Test.

<ins>Note:</ins> Live deployments via startup daemons are only supported on Linux distributions with systemd.

* Works with Linux, macOS, and Windows Subsystem for Linux.

Install

Copy and paste the following commands into your terminal:

Native binaries

Before you pipe any script into your computer, always view the source code and make sure you understand what it does.

wget -qO- https://ind.ie/web-server/install.sh | bash

Node.js

npm i -g @ind.ie/web-server

Uninstall

To uninstall the native binary (and any created artifacts, like TLS certificates, systemd services, etc.):

web-server uninstall

Use

Local

Start serving the current directory at https://localhost as a regular process using locally-trusted certificates:

$ web-server

Proxy server (local)

You can use Indie Web Server as a development-time reverse proxy for HTTP and WebSocket connections. For example, if you use Hugo and you’re running hugo server on the default HTTP port 1313. You can run a HTTPS reverse proxy at https://localhost with LiveReload support using:

$ web-server proxy localhost:1313

This will create and serve the following proxies:

• http://localhost:1313 → https://localhost
• ws://localhost:1313 → wss://localhost

Live sync to remote server

Part of local development involves deploying your changes to a live server at some point. You can use Indie Web Server to handle this for you in real-time:

$ web-server sync my-demo my-demo.site

The above command will start a local development server at https://localhost. Additionally, it will watch the folder my-demo for changes and sync any changes to its contents via rsync over ssh to my-demo.site. Without any customisations, the sync command assumes that your account on your remote server has the same name as your account on your local machine and that the folder you are watching (my-demo, in the example above) is located at /home/your-account/my-demo. Also, by default, the contents of the folder will be synced, not the folder itself. You can change these defaults using optional arguments.

$ web-server sync my-folder --host=my-demo.site --account=a-different-account --folder=not-my-folder

e.g., The above command will watch the the contents of the my-folder directory and sync it to _a-different-account@my-demo.site:/home/a-different-account/not-my-folder_.

You can also customise the destination folder completely but supplying a custom remote connection string using the --to option:

$ web-server sync my-folder --to=some-account@my-demo.site:/var/www

Like the other commands, if you do not specify a folder, the current folder will be used by default.

If you want to sync not the folder’s contents but the folder itself, use the --sync-folder-and-contents flag. e.g.,

$ web-server sync my-local-folder/ my.site --account=me --folder=my-remote-folder

The above command will result in the following directory structure on the remote server: /home/me/my-remote-folder/my-local-folder

If you want to carry out a one-time sync and not continue to run the web server afterwards, use the --exit-on-sync flag. e.g.,

$ web-server sync my-folder my-demo.site --exit-on-sync

Global (ephemeral)

Start serving the site directory at your hostname as a regular process using globally-trusted Let’s Encrypt certificates:

$ web-server global site

Then use, for example, ngrok (Pro+) to point a custom domain name to your temporary staging server. Make sure you set your hostname file (e.g., in /etc/hostname or via hostnamectl set-hostname <hostname> or the equivalent for your platform) to match your domain name. The first time you hit your server via your hostname it will take a little longer to load as your Let’s Encrypt certificates are being automatically provisioned by ACME TLS.

When you start your server using the global command, it will run as a regular process. It will not be restarted if it crashes or if you exit the foreground process or restart the computer.

Global (persistent)

Available on Linux distributions with systemd (most Linux distributions, but not these ones or on macOS).

Start serving the site directory at your hostname as a daemon that is automatically run at system startup and restarted if it crashes:

$ web-server enable site

The enable command sets up your server to start automatically when your server starts and restart automatically if it crashes. Requires superuser privileges on first run to set up the launch item.

For example, if you run the command on a connected server that has the ar.al domain pointing to it and ar.al set in /etc/hostname, you will be able to access the site at https://ar.al. The first time you hit it, it will take a little longer to load as your Let’s Encrypt certificates are being automatically provisioned by ACME TLS.

When the server is enabled, you can also use:

• disable: Stop server and remove from startup.
• logs: Display and tail server logs.
• status: Display detailed server information (press ‘q’ to exit).

Indie Web Server uses the systemd to start and manage the daemon. Beyond the commands listed above that Indie Web Server supports natively (and proxies to systemd), you can make use of all systemd functionality via the systemctl and journalctl commands.

Build and test from source

Global Node.js module

# Clone and install.
git clone https://source.ind.ie/hypha/tools/web-server.git
cd web-server
npm i         # Install modules and development dependencies.
npm i -g .    # Install globally for access to the binary.

# Run unit tests.
npm test

# Serve the test site (visit https://localhost to view).
web-server test/site

Note: for commands that require root privileges (i.e., enable and disable), Indie Web Server will automatically restart itself using sudo and Node must be available for the root account. If you’re using nvm, you can enable this via:

# Replace v10.15.3 with the version of node you want to make available globally.
sudo ln -s "$NVM_DIR/versions/node/v10.15.3/bin/node" "/usr/local/bin/node"
sudo ln -s "$NVM_DIR/versions/node/v10.15.3/bin/npm" "/usr/local/bin/npm"

Native binaries

# Clone and install.
git clone https://source.ind.ie/hypha/tools/web-server.git
cd web-server
npm i         # Install modules and development dependencies.

# Run unit tests.
npm test

# Build the native binary for your platform.
# To build for all platforms, use npm run build -- --all
npm run build

# Serve the test site (visit https://localhost to view).
# e.g., To run the version 9.2.2 Linux binary:
dist/linux/9.2.2/web-server test/site

Build and install native binary locally

npm run install-locally

Deployment

# To build binaries for both linux and macOS and also to
# copy them over to the Indie Web Site for deployment.
# (You will most likely not need to do this.)
npm run deploy

Syntax

web-server [command] [folder|host] [host] [--options]

• command: version | help | local | global | proxy | sync | enable | disable | logs | status
• folder|host: Path of folder to serve (defaults to current folder) or host to proxy or sync.
• host: Host to sync.
• options: Settings that alter server characteristics.

Commands:

• version: Display version and exit.
• help: Display help screen and exit.
• local: Start server as regular process with locally-trusted certificates.
• global: Start server as regular process with globally-trusted certificates.
• proxy: Start server to proxy provided HTTP URL via HTTPS. Also proxies WebSockets.
• sync: Start server as regular process with locally-trusted certificates and rsync folder to host.

On Linux distributions with systemd, you can also use:

• enable: Start server as daemon with globally-trusted certificates and add to startup.
• disable: Stop server daemon and remove from startup.
• logs: Display and tail server logs.
• status: Display detailed server information.

If command is omitted, behaviour defaults to local.

Options:

• --port=N: Port to start server on (defaults to 443).

For the enable command:

• --sync: Ensure the server can also rsync via ssh (so you can sync your site to it from your local machine).

For the sync command:

• --host: The remote host to sync to (e.g., my-demo.site).
• --account: The ssh account to use on remote server (defaults to same as on current session).
• --folder: The subfolder of home folder to sync to on remote machine (defaults to name of served folder).
• --proxy: Proxy the specified host and port instead of starting a regular local server.
• --exit-on-sync: Exit once the first sync has occurred. Useful in deployment scripts.
• --sync-folder-and-contents: Sync folder and contents (default is to sync the folder’s contents only).

All command-line arguments are optional. By default, Indie Web Server will serve your current working folder over port 443 with locally-trusted certificates.

If you want to serve a directory that has the same name as a command, you can specify the command in options format. e.g., web-server --enable logs will start Indie Web Server as a startup daemon to serve the logs folder.

When you use the global or enable commands, globally-trusted Let’s Encrypt TLS certificates are automatically provisioned for you using ACME TLS the first time you hit your hostname. The hostname for the certificates is automatically set from the hostname of your system (and the www. subdomain is also automatically provisioned).

Usage examples

Develop using locally-trusted certificates:

Stage and deploy using globally-trusted Let’s Encrypt certificates:

Native support for an Evergreen Web

What if links never died? What if we never broke the Web? What if it didn’t involve any extra work? It’s possible. And, with Indie Web Server, it’s easy.

Native cascading archives support

If you have a static archive of the previous version of your site, you can have Indie Web Server automatically serve it for you. For example, if your site is being served from the my-site folder, just put the archive of your site into a folder named my-site-archive-1:

|- my-site
|- my-site-archive-1

If a path cannot be found in my-site, it will be served from my-site-archive-1.

And you’re not limited to a single archive (and hence the “cascade” bit in the name of the feature). As you have multiple older versions of your site, just add them to new folders and increment the archive index in the name. e.g., my-site-archive-2, my-site-archive-3, etc.

Paths in my-site will override those in my-site-archive-3 and those in my-site-archive-3 will, similarly, override those in my-site-archive-2 and so on.

What this means that your old links will never die but if you do replace them with never content in never versions, those will take precedence.

Native 404 → 302 support

But what if the previous version of your site is a dynamic site and you either don’t want to lose the dynamic functionality or you simply cannot take a static backup. No worries. Just move it to a different subdomain or domain and make your 404s into 302s.

Indie Web Server has native support for the 404 to 302 technique to ensure an evergreen web. Just serve the old version of your site (e.g., your WordPress site, etc.) from a different subdomain and tell Indie Web Server to forward any unknown requests on your new static site to that subdomain so that all your existing links magically work.

To do so, create a simple file called 4042302 in the root directory of your web content and add the URL of the server that is hosting your older content. e.g.,

/4042302

https://the-previous-version-of.my.site

You can chain the 404 → 302 method any number of times to ensure that none of your links ever break without expending any additional effort to migrate your content.

For more information and examples, see 4042302.org.

Custom error pages

You can specify a custom error page for 404 (not found) and 500 (internal server error) errors. To do so, create a folder with the status code you want off of the root of your web content (i.e., /404 and/or /500) and place at least an index.html file in the folder. You can also, optionally, put any assets you want to display on your error pages into those folders and load them in via relative URLs. Your custom error pages will be served with the proper error code and at the URL that was being accessed.

If you do not create custom error pages, the built-in default error pages will be displayed for 404 and 500 errors.

When creating your own servers (see API), you can generate the default error pages programmatically using the static methods WebServer.default404ErrorPage() and WebServer.default500ErrorPage(), passing in the missing path and the error message as the argument, respectively to get the HTML string of the error page returned.

Dynamic routes

You can include very basic dynamic routes by including JavaScript files that export middleware-style functions in a special .dynamic folder in the root folder of your web content. The syntax and conventions are detailed here.

So, for example, if you wanted to have a dynamic route that showed the server CPU load and free memory, you could create a file called .dynamic/server-stats.js in your web folder with the following content:

const os = require('os')

function serverStats (request, response, next) {

  const loadAverages = `<p> ${os.loadavg().reduce((a, c, i) => `${a}\n<li><strong>CPU ${i+1}:</strong> ${c}</li>`, '<ul>') + '</ul>'}</p>`

  const freeMemory = `<p>${os.freemem()} bytes</p>`

  const page = `<html><head><title>Server statistics</title><style>body {font-family: sans-serif;}</style></head><body><h1>Server statistics</h1><h2>Load averages</h2>${loadAverages}<h2>Free memory</h2>${freeMemory}</body></html>`

  response.end(page)
}

module.exports = serverStats

Indie Web Server will load your dynamic route at startup and you can test it by hitting https://localhost/server-stats using a local web server. Each time you refresh, you should get the latest dynamic content.

If you need to use custom Node modules, initialise your .dynamic folder using npm init and use npm install as usual. And modules you require from your routes will be properly loaded and used.

Directories

Your dynamic web routes are running within Indie Web Server, which is a Node application compiled into a native binary.

• os.homedir(): (writable) This is the home folder of the account running Indie Web Server. You can write to it to store persistent objects (e.g., save data).

• os.tmpdir(): (writable) Path to the system temporary folder. Use for content you can afford to lose and can recreate (e.g., cache API calls).

• .: (writable) Path to the root of your web content. Since you can write here, you can, if you want to, create content dynamically that will then automatically be served by the static web server.

• __dirname: (writeable) Path to the .dynamic folder.

• /: (read-only) Path to the /usr folder (Indie Web Server is installed in /usr/local/web-server). You should not have any reason to use this.

If you want to access the directory of Indie Web Server itself (e.g., to load in the package.json to read the app’s version), you can use the following code:

const appPath = require.main.filename.replace('bin/web-server.js', '')

Security

The code within your JavaScript routes is executed on the server. Exercise the same caution as you would when creating any Node.js app (sanitise input, etc.)

Intended usage

You shouldn’t use this functionality to create your latest amazing web app. For that, include Indie Web Server as a node module in your project and extend it that way. This is to add tiny bits of dynamic functionality. There is currently only support for get routes. Again, if you need custom modules, extend Indie Web Server using Node.js.

API

Indie Web Server’s createServer method behaves like the built-in https module’s createServer function. Anywhere you use require('https').createServer, you can simply replace it with require('@ind.ie/web-server').createServer.

createServer([options], [requestListener])

• options (object): see https.createServer. Populates the cert and key properties from the automatically-created nodecert or Let’s Encrypt certificates and will overwrite them if they exist in the options object you pass in. If your options has options.global = true set, globally-trusted TLS certificates are obtained from Let’s Encrypt using ACME TLS.

• requestListener (function): see https.createServer. If you don’t pass a request listener, Indie Web Server will use its default one.

  Returns: https.Server instance, configured with either locally-trusted certificates via nodecert or globally-trusted ones from Let’s Encrypt.

Example

const webServer = require('@ind.ie/web-server')
const express = require('express')

const app = express()
app.use(express.static('.'))

const options = {} // to use globally-trusted certificates instead, set this to {global: true}
const server = webServer.createServer(options, app).listen(443, () => {
  console.log(` 🎉 Serving on https://localhost\n`)
})

serve([options])

Options is an optional parameter object that may contain the following properties, all optional:

• path (string): the directory to serve using Express.static.

• callback (function): a function to be called when the server is ready. If you do not specify a callback, you can specify the port as the second argument.

• port (number): the port to serve on. Defaults to 443. (On Linux, privileges to bind to the port are automatically obtained for you.)

• global (boolean): if true, globally-trusted Let’s Encrypt certificates will be provisioned (if necesary) and used via ACME TLS. If false (default), locally-trusted certificates will be provisioned (if necesary) and used using nodecert.

  Returns: https.Server instance, configured with either locally or globally-trusted certificates.

Examples

Serve the current directory at https://localhost using locally-trusted TLS certificates:

const webServer = require('@ind.ie/web-server')
const server = webServer.serve()

Serve the current directory at your hostname using globally-trusted Let’s Encrypt TLS certificates:

const webServer = require('@ind.ie/web-server')
const server = webServer.serve({global: true})

Contributing

Indie Web Server is, by design, a zero-configuration personal web server for single-tenant web applications for and by individuals. As such, any new feature requests will have to be both fit for purpose and survive a trial by fire to be considered. (That is, this is Small Tech, with the emphasis on small).

Please file issues and submit pull requests on the Indie Web Server Github Mirror.

Help wanted

For locally-trusted certificates, all dependencies are installed automatically for you if they do not exist if you have apt, pacman, or yum (untested) on Linux or if you have Homebrew or MacPorts (untested) on macOS.

I can use your help to test Indie Web Server on the following platform/package manager combinations:

• Linux with yum
• macOS with MacPorts

Please let me know how/if it works. Thank you!

Thanks

• thagoat for confirming that installation works on Arch Linux with Pacman.

• Tim Knip for confirming that the module works with 64-bit Windows with the following behaviour: “Install pops up a windows dialog to allow adding the cert.” Note: Indie Web Server is not supported on Windows. Please use Windows Subsystem for Linux.

• Run Rabbit Run for the following information on 64-bit Windows: “Win64: works with the windows cert install popup on server launch. Chrome and ie are ok with the site then. FF 65 still throws the cert warning even after restarting.” Note: Indie Web Server is not supported on Windows. Please use Windows Subsystem for Linux.