Logdy 0.17.1

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, choose your Region, then choose Launch through EC2. Select m5.large (Logdy itself is very light), your key pair and a security group as above.

To launch with the AWS CLI instead, 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}]'

For Logdy 0.17.1 on Ubuntu 24.04, the SSH user is ubuntu. Connect with your key pair.

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

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

First boot takes a few seconds. It generates the password and the certificate, and then nginx starts in front of Logdy. Check the services.

systemctl is-active logdy-firstboot logdy logdy-demo nginx
sudo test -f /var/lib/sac/data/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. Check the listening sockets.

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-sac.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

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

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. Inspect the certificate.

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

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = sac 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>

These checks confirm the following:

• Port 80 redirects to HTTPS.
• /health answers without a login.
• The interface refuses a missing or wrong password and accepts yours.
• The instance drops a request for a host name it does not serve.

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. It runs the same checks, then opens the live WebSocket stream through nginx with your password. It confirms that new lines arrive while the stream 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]

Open the LOGDY_URL address from Step 4 in your browser. The certificate is self-signed and 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. The left rail shows each column's values with live counts.

Click a value in the left rail to filter the stream. For example, ERROR under level narrows the stream to the error lines, and every count updates as new lines arrive. Choose Reset all filters to clear 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. It lists every field of that line and steps to the next or previous line. Choose Show/hide raw message to see the original JSON.

The demo generator exists only to fill the interface on first boot. It writes a structured JSON line every two seconds to /var/log/logdy-demo/app.log. Look at the latest line.

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

{"time":"2026-10-20T22:26:06Z","level":"INFO","service":"search","source":"sac-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, which keep Logdy on loopback with analytics and update checks off. Add the log's directory to ReadWritePaths= only if Logdy must write there, because it needs only 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 the user 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. Alternatively, 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.

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.

SecureAnyCloud compiles the unmodified 0.17.1 source instead. The build uses 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 build record ships on the image. Print its key lines and the binary checksum.

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

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. The helper 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, and 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

• 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, with no passwords, no root login and 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.