Breaking changes in v0.1.13: Binary linking and hardcoded paths issues

[hwoarang84]

Hello,
I've noticed that starting from version 0.1.13, several significant breaking changes were introduced that affect deployment in Docker environments (specifically Alpine-based images).

1. Dynamic Linking vs. Static Linking
The release binary for linux_amd64 appears to be dynamically linked now. When running in an Alpine Linux container, it fails with the error:
exec /path/to/binary: no such file or directory
This happens because the binary now depends on glibc (e.g., ld-linux-x86-64.so.2), which is absent in Alpine. To fix this, users are forced to install libc6-compat, whereas previous versions worked fine as static binaries.
Suggestion: Consider building the release binaries with CGO_ENABLED=0 to ensure they are statically linked and portable across different distributions?

2. Hardcoded Data Paths
The default paths for the database and uploads seem to have shifted to /lib/db_data and /lib/uploads. Previously, the application relied on relative paths or different defaults (e.g. /cdn/).
In version 0.1.13, even if volumes are mounted to the old locations, the app ignores them and creates a new empty database in /lib/db_data.
Suggestion: It would be highly beneficial to allow these paths to be configurable via Environment Variables (e.g., DB_PATH, UPLOAD_PATH) or CLI flags, rather than having them hardcoded to system directories like /lib.

3. Missing Configuration Keys in Existing Databases
Updating to v0.1.13 with an existing database triggers record not found errors for new keys like access_token_ttl. While not fatal, it litters the logs.
Suggestion: Implementing an automatic migration or default value assignment for missing config keys would improve the upgrade experience.

These changes broke existing deployment scripts and automated CI/CD pipelines. It would be great if such "Breaking Changes" were documented in the Release Notes.

Best regards.

[hwoarang84]

I noticed your Dockerfile in v0.1.13 sets WORKDIR /lib. This is why the app defaults to /lib/db_data/ for the database. It would be much better to use a dedicated directory like /app or /data and allow overriding it via ENV variables.