Logdy 0.17.1 on AWS User Guide

Overview

This guide covers launching and using the Logdy 0.17.1 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg log management listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Logdy is an open source, self hosted, real time log viewer. It follows a log file on the instance and streams every new line to a browser, where structured JSON logs are parsed into sortable columns with faceted filters, full text search and a detail drawer for each line. It is a single Go binary that keeps the lines it shows in an in memory buffer, so there is no database to run or back up.

An upstream Logdy binary serves its interface with no login. The cloudimg image changes that:

• HTTPS from the first boot. nginx is the only network entry point and serves Logdy on port 443 with a certificate generated on your instance's first boot. Port 80 only redirects to HTTPS.
• A password unique to your instance. The whole interface, including the WebSocket that streams the log lines and every /api path, needs HTTP Basic Auth as the user admin. The password is generated on first boot and written to the root only file /root/logdy-info.txt; nginx stores only its bcrypt hash. No password is baked into the image and no two instances share one. Only a static /health endpoint answers without a login.
• Logdy on loopback only, no network ingest. Logdy listens on 127.0.0.1:8080 and only follows files on the instance. Its socket, forward and HTTP ingest modes are not enabled, so nothing on the network can push lines into your viewer.
• Fail closed. nginx refuses to start until first boot has written the certificate and the password, so the interface is never served without a login.
• Built from source with a current toolchain. The newest upstream release binary was built with an old Go toolchain that carries known Go security advisories. cloudimg compiles the unmodified Logdy 0.17.1 source with Go 1.27.3 instead (details in Step 9).
• Key only SSH. Password logins, root logins and X11 forwarding are switched off.
• Hardened service. Logdy and the demo generator run as an unprivileged logdy user in a systemd sandbox. Requests for a host name the instance does not serve are dropped, cross site WebSocket connections are refused, and nginx logs the real client address rather than any X-Forwarded-For header a client sends.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: Logdy 0.17.1 (/usr/local/bin/logdy, Apache License 2.0), a column and facet layout for the demo log (/etc/logdy/logdy.config.json), a small demo log generator so the interface has data on first sign in, nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows TCP 22 (SSH), TCP 443 (the Logdy interface) and TCP 80 (redirects to HTTPS) from your own networks only. Never open port 8080; Logdy listens on loopback.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Logdy 0.17.1 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large (Logdy itself is very light), your key pair and a security group as above.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=logdy}]'

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows the web address and where to find the password.

Step 3: Check the services

First boot takes a few seconds: it generates the password and the certificate, then nginx starts in front of Logdy:

systemctl is-active logdy-firstboot logdy logdy-demo nginx
sudo test -f /var/lib/cloudimg/logdy-firstboot.done && echo FIRSTBOOT_DONE
/usr/local/bin/logdy --version

active
active
active
active
FIRSTBOOT_DONE
logdy version 0.17.1

Only SSH and nginx listen on public addresses; Logdy listens on loopback:

sudo ss -Hlntp | awk '{print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort

0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"))
127.0.0.1:8080 users:(("logdy"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("nginx"),("nginx"),("nginx"))
[::]:80 users:(("nginx"),("nginx"),("nginx"))

SSH accepts keys only: passwords, root logins and X11 forwarding are switched off in /etc/ssh/sshd_config.d/00-cloudimg.conf, which sorts before every other SSH setting. Check the effective values:

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|x11forwarding|pubkeyauthentication) '

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no

Step 4: Get your address and password

The address and user name are in the root only file /root/logdy-info.txt:

sudo grep -E '^LOGDY_(URL|UI_USERNAME)=' /root/logdy-info.txt

LOGDY_UI_USERNAME=admin
LOGDY_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/

The password is the LOGDY_UI_PASSWORD line of the same file: sudo grep '^LOGDY_UI_PASSWORD=' /root/logdy-info.txt. Store it in your password manager; it is unique to this instance.

The address uses the instance's public DNS name from EC2 instance metadata (IMDSv2), or its public or private IPv4 address when it has no public name. The certificate names that host plus the instance's public and private IP addresses:

openssl x509 -in /etc/ssl/logdy/logdy.crt -noout -subject -ext subjectAltName -enddate

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name:
    DNS:ec2-<public-ip-dashed>.compute-1.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost
notAfter=<date about 27 months after first boot>

Step 5: Check the login

Port 80 redirects to HTTPS, /health answers without a login, the interface refuses a missing or wrong password and accepts yours, and a request for a host name the instance does not serve is dropped. The commands read the password into a shell variable and hand it to curl through a file descriptor, so it never appears in the process list or your shell history:

H=$(sudo sed -n 's#^LOGDY_URL=https://\([^/]*\)/.*#\1#p' /root/logdy-info.txt)
PW=$(sudo sed -n 's/^LOGDY_UI_PASSWORD=//p' /root/logdy-info.txt)
CA=/etc/ssl/logdy/logdy.crt
curl -s -o /dev/null -w 'http://        -> %{http_code} %{redirect_url}\n' --resolve "$H:80:127.0.0.1" "http://$H/"
curl -s -w ' <- health, HTTP %{http_code}\n' --cacert $CA --resolve "$H:443:127.0.0.1" "https://$H/health"
curl -s -o /dev/null -w 'no login       -> HTTP %{http_code}\n' --cacert $CA --resolve "$H:443:127.0.0.1" "https://$H/"
curl -s -o /dev/null -w 'wrong password -> HTTP %{http_code}\n' --cacert $CA --resolve "$H:443:127.0.0.1" -u admin:not-the-password "https://$H/"
curl -s -o /dev/null -w 'your password  -> HTTP %{http_code}\n' --cacert $CA --resolve "$H:443:127.0.0.1" -K <(printf 'user = "admin:%s"\n' "$PW") "https://$H/"
curl -sk -o /dev/null -w 'other host     -> HTTP %{http_code} (000 = connection dropped)\n' -H 'Host: evil.example' https://127.0.0.1/ || true

http://        -> 301 https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/
OK
 <- health, HTTP 200
no login       -> HTTP 401
wrong password -> HTTP 401
your password  -> HTTP 200
other host     -> HTTP 000 (000 = connection dropped)

--resolve sends the request to this instance while keeping the real host name, so the certificate check passes. From another machine, drop --resolve and use the address directly.

The image also carries a self test that runs the same checks and then opens the live WebSocket stream through nginx with your password, confirming new lines arrive while it is connected and that Logdy's HTTP ingest endpoint stays closed:

sudo /usr/local/sbin/logdy-selftest.sh

OK logdy round-trip over https: health-200 public, UI 401-without / 200-with per-VM creds, wrong-401, api/log ingest off, demo log streaming via WebSocket [demo_lines=75 streamed_live_after_5s=3 seq_range=1-75]

Step 6: Sign in to the web interface

Open the LOGDY_URL address from Step 4 in your browser. The certificate is self signed (made on your instance), so your browser asks you to accept it once; Step 10 shows how to use your own name and certificate. When the browser asks for a login, enter admin and your password.

Logdy opens on the demo log and keeps streaming: each JSON line is split into columns for time, level, service, method, path, status, duration and message, and the left rail shows each column's values with live counts.

Step 7: Filter, search and inspect

Click a value in the left rail to filter the stream; for example ERROR under level narrows it to the error lines, with every count updating as new lines arrive. Reset all filters clears them. The search box at the top takes free text and field queries across the parsed columns.

Click a row to open the detail drawer, which lists every field of that line and steps to the next or previous line. Show/hide raw message shows the original JSON.

Step 8: Point Logdy at your own logs

The demo generator only exists to fill the interface on first boot; it writes a structured JSON line every two seconds to /var/log/logdy-demo/app.log:

tail -n 1 /var/log/logdy-demo/app.log

{"time":"2026-10-20T22:26:06Z","level":"INFO","service":"search","source":"cloudimg-demo","host":"vm-01","method":"PATCH","path":"/healthz","status":200,"duration_ms":447,"seq":76,"message":"queue drained"}

When you are ready to view your own logs, stop the demo and repoint Logdy. These commands change the service, so run them yourself:

sudo systemctl disable --now logdy-demo.service
sudo systemctl edit --full logdy.service

In the editor, change the file in the ExecStart line from /var/log/logdy-demo/app.log to your own log, keep the other options (they keep Logdy on loopback with analytics and update checks off), and add the log's directory to ReadWritePaths= only if Logdy must write there (it only needs to read). For example:

ExecStart=/usr/local/bin/logdy follow /var/log/myapp/app.log --full-read --config /etc/logdy/logdy.config.json --port 8080 --ui-ip 127.0.0.1 -n -u

The logdy user must be able to read the file (for system logs in /var/log, add it to the adm group with sudo usermod -aG adm logdy). Then apply the change:

sudo systemctl daemon-reload
sudo systemctl restart logdy.service

/etc/logdy/logdy.config.json defines the columns and facets for the demo log's fields. For your own format, adjust the columns in the interface (the gear icon) and export the layout over that file, or remove --config to start from Logdy's defaults. The Logdy documentation at https://logdy.dev/docs covers columns, parsers and the other input modes. If you enable a network input (socket, forward or the HTTP ingest API with --api-key), keep its port closed in your security group except to the hosts that send logs.

Step 9: How the Logdy binary was built

The newest upstream release, 0.17.1, publishes a binary built with Go 1.23.2 and older WebSocket and networking libraries, which carry known Go security advisories. cloudimg compiles the unmodified 0.17.1 source instead, with the official Go 1.27.3 toolchain, gorilla/websocket raised from 1.5.1 to 1.5.3 (a patch release with a security fix) and the module set to current Go defaults. The build is reproducible, and Go's own vulnerability scanner reports nothing for the shipped binary. The record ships on the image:

grep -E '^(toolchain  |dependency  |module language|binary sha256|govulncheck  )' /usr/share/doc/logdy/BUILD-PROVENANCE.txt
sha256sum /usr/local/bin/logdy

toolchain         go1.27.3 linux/amd64, official tarball https://go.dev/dl/go1.27.3.linux-amd64.tar.gz
dependency        github.com/gorilla/websocket v1.5.1 -> v1.5.3 (GO-2026-6278; go get via the module proxy + sum.golang.org)
module language   go 1.23.2 -> go 1.27.0 (no DefaultGODEBUG compatibility overrides: every current Go security default applies)
binary sha256     96b857fc429cc196b6eeff8d29d55e1a4dbfddece3faa2d261817a5486f8942d (reproducible build)
govulncheck       v1.9.0 -mode=binary on the compiled binary: no vulnerabilities found
96b857fc429cc196b6eeff8d29d55e1a4dbfddece3faa2d261817a5486f8942d  /usr/local/bin/logdy

Step 10: Use your own DNS name, certificate or password

The served host name comes from configuration, never from a request. To serve Logdy under your own DNS name, point the name at the instance and run the helper, which records the name, makes a new self signed certificate for it, updates /root/logdy-info.txt and reloads nginx:

sudo logdy-set-hostname logs.example.com

To use a certificate from your own certificate authority instead, put the full chain in /etc/ssl/logdy/logdy.crt and the private key in /etc/ssl/logdy/logdy.key (owner root, mode 0600), then run sudo nginx -t && sudo systemctl reload nginx. Running logdy-set-hostname again replaces them with a self signed pair.

To change the password, let htpasswd prompt for it (never put a password on the command line), then reload nginx and update your note in /root/logdy-info.txt:

sudo htpasswd -B /etc/nginx/logdy.htpasswd admin
sudo systemctl reload nginx

Step 11: Security notes and operations

• Restrict ports 443 and 80 to the networks your team uses; port 8080 is never exposed.
• Logdy shows whatever the followed file contains to anyone with the password. Point it only at logs your viewers may see, and give separate teams separate instances.
• Logdy keeps lines in memory only: a restart clears the view and nothing is written to disk unless you add --append-to-file. There is no database to back up.
• SSH accepts key logins as ubuntu only (no passwords, no root login, no X11 forwarding); use sudo for administration.
• The AMI requires IMDSv2. nginx logs the real client address of every request and ignores X-Forwarded-For headers sent by clients.
• Manage the services with systemctl status logdy nginx and read their logs with journalctl -u logdy -u nginx. Unattended upgrades keep Ubuntu and nginx patched; check the listing for newer Logdy versions.

Support and licensing

Logdy is open source under the Apache License 2.0; the licence, README and build record are in /usr/share/doc/logdy/. There is no per user or per CPU licence fee; the AMI price covers cloudimg's hardening, first boot setup, the source build and support.

• Email: support@cloudimg.co.uk
• Website: https://www.cloudimg.co.uk

Logdy is developed by the Logdy project (logdyhq); for Logdy features, see the upstream documentation at https://logdy.dev/docs.

Logdy is a trademark of its respective owner. cloudimg is not affiliated with or endorsed by the Logdy project; the name is used only to identify the upstream software.