gdy666/lucky

What it does

Lucky bundles the networking chores of a home or small office network into one web interface: dynamic DNS, reverse proxying and redirects, TCP/UDP port forwarding, SSL/TLS certificate issuance and renewal, NAT traversal via STUN, Cloudflared, or FRP, and file services such as WebDAV, Samba, FTP, FileBrowser, DLNA, and Rclone. It also covers Wake-on-LAN, scheduled tasks, Docker management, a web terminal, IP filtering, security groups, Coraza WAF, third-party authentication, and Passkey management (module overview).

It began as a way to forward public IPv6 traffic to private IPv4 devices on a router, and now runs on routers, NAS devices, and servers. The intended audience is people who administer their own network and want these tasks in one place rather than in a stack of separate scripts and daemons.

Quick start

Prerequisites: a supported device (Linux, Windows, macOS, OpenWrt router, NAS, or a Docker host) and a configuration directory you control.

1. Choose the build for your platform using the build comparison, then install via the official installation guide and release packages. OpenWrt users can use luci-app-lucky. Packages in NAS app stores may vary in version and update schedule.
2. Start the service and open http://DEVICE_IP:16601 in a browser. The default username and password are both 666 (getting started).
3. Immediately change the default credentials, set a security entry path, and restrict who can reach the management interface.
4. Use Quick Start in the interface to configure the modules you need, for example DDNS, certificates, Web Services, or port forwarding. Actual external access also depends on your public address, router, and firewall.
5. Back up the configuration before upgrading, migrating, or downgrading.

For Docker on Linux with host networking, the documented example runs the v3 Beta image and mounts a configuration directory:

docker run -d \
  --name lucky \
  --restart=always \
  --net=host \
  -v /root/luckyconf:/app/conf \
  gdy666/lucky:v3

Replace /root/luckyconf with a directory on the host so configuration survives container recreation. The v3 tag follows Beta updates, and older images may use a different configuration path inside the container (Docker example).

Source and licensing

The repository is MIT-licensed, but the published source only covers versions through 1.4.10; later releases are not open-sourced and differ from the historical code here. Treat current binaries as closed-source builds and refer to the README's source-availability note (README) when evaluating the project.

Usage constraints

Feature availability depends on the build, platform, and runtime environment, so check the build comparison and module documentation before committing to a package. Docker management and similar functions need extra configuration and permissions; avoid exposing the Docker socket unnecessarily (installation notes).

Exposing services makes authentication and network filtering matter: use strong passwords, open only required ports, and keep both Lucky and the proxied services patched. The web terminal, Docker management, and file services deserve especially tight access control (security notes).

According to the linked usage notice, Lucky reports its version, OS type, architecture, and a randomly generated device identifier; the identifier does not include a MAC address or disk serial number. Read the full notice before deploying. When restoring configurations across versions, follow the compatibility guidance.

HotRepo's take

The only recorded ranking is a Go-language daily snapshot on 2026-11-03, when Lucky placed 9th in that list and sat at 8,311 stars with 745 forks. That single observation supports the fact that the project was drawing attention in Go circles on that day, but there is no multi-day series here to describe a trend, and no all-language daily rank is recorded. The technical picture is a mature, broad utility with a deliberately limited open-source surface: a practical choice for self-hosters who want one managed entry point for DDNS, proxying, and certificates, provided they are comfortable with current releases being closed binaries from the official distribution channel.