#getting-started
While silverBullet works over plain HTTP on a LAN IP or hostname in online-only mode, HTTPS enables the full feature set, including offline use and local encryption. This page documents a few deployment options.
note Note This is a browser enforced restriction: browsers restrict service workers, crypto, and programmatic clipboard access to secure contexts. This is why the recommended deployment model is TLS, but SilverBullet will make a best effort to work without it.
Open your server using its LAN address, for example http://192.168.1.20:3000. The server must listen on an address reachable from your LAN. Editing, indexing, queries, Space Lua, plugs, attachments, and local password login remain available.
The limitations are:
And obviously, HTTP does not encrypt or authenticate network traffic: credentials, notes, and application code can be intercepted or modified by someone with access to the connection.
If you run SilverBullet locally on your machine, this is the easiest option. Everything runs fine as long as the browser sees localhost or 127.0.0.1 appear in the URL, even with http://.
The obvious drawback of this approach is that your SilverBullet instance is only accessible from the machine you run it on.
For this, you need to get your hands on a TLS certificate.
A few options:
If you’re already using a proxy like Pangolin, Authelia or Authentik, you are likely already set up with everything you need and can just reverse-proxy a subdomain to SilverBullet. Be sure to check the notes on using a Authentication Proxy on how to configure this.
If you’re a Tailscale user, this a simple solution. If not, you may consider becoming one — it’s a solid service, very friendly to self hosters, and free for this use case.
Part of the guide to setup SilverBullet on Linux are instructions on how to install (a free service) and use it to expose a local server (like SilverBullet) locally on your VPN, or the Internet — a setup that gives you a .ts.net subdomain with TLS certificate.
The advantage of this approach is that you have the choice to expose your SilverBullet to the wide Internet, or limit it to just your Tailscale VPN. The disadvantage is that you now rely on a third party (Tailscale).
There a various affordable providers of cloud servers that can be used to self-host SilverBullet in the cloud. It relatively easy to get a TLS certificate issued on a publicly exposed server.
The recommended approach for this requires two things:
*.duckdns.org sub-domain for free.After deploying SilverBullet on the VM (with Authentication enabled, obviously), you can deploy Caddy next to it as a reverse proxy. Caddy can automatically request TLS certificates using Let’s Encrypt.
For this, install Caddy into your VM. Then, in your Caddyfile (usually located /etc/caddy/Caddyfile) put:
silverbullet.mydomain.com {
reverse_proxy localhost:3000
}
Replace silverbullet.mydomain.com with any domain that you have configured to resolve to the IP of your server, and the :3000 port with whatever local port you run SilverBullet on.
Restart Caddy and access SilverBullet via https://silverbullet.mydomain.com. On first load, Caddy will work with Let’s Encrypt to issue a TLS certificate and install (and update) it automatically, this may take a minute, so be patient.
Whichever reverse proxy you use, make sure it serves SilverBullet over HTTP/2. Over HTTP/1.1, browsers allow only six simultaneous connections per host, and SilverBullet’s service worker and sync engine can use all of them. When that happens, every request stalls: the client reports “Could not reach remote server, we’re offline or the server is down”, requests to /.ping time out, and pages load slowly from the local copy, even though the server itself is up.
http2 on; to the server block (nginx 1.25.1 and later), or use listen 443 ssl http2; on older versions.To check, run the following, which should print 2:
curl -s -o /dev/null -w '%{http_version}\n' https://silverbullet.mydomain.com/.ping
SilverBullet keeps a server-sent events stream open at /.events for live updates. The server sends a ping on it every 30 seconds. If your reverse proxy buffers or compresses this stream, those pings never reach the browser. Live updates then fall back to polling, and stale streams can pile up in the browser and hold connections open.
Caddy passes event streams through unbuffered, so the configuration above needs no changes. If you added an encode directive, make sure it doesn’t apply to text/event-stream.
nginx: add a location for /.events next to your existing one, with buffering and compression turned off:
location /.events {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_buffering off;
proxy_cache off;
gzip off;
proxy_read_timeout 1h;
}
Nginx Proxy Manager: edit the proxy host, open the Advanced tab and paste the same block, with proxy_pass $forward_scheme://$server:$port; so it uses the host’s forward settings.
For end-to-end walkthroughs of specific setups, the community has written several guides: