Fixed error: "docker exporter does not currently support exporting manifest lists"
The issue occurred because SBOM and provenance attestations create manifest
lists, which cannot be loaded to the local Docker daemon (required for PRs).
Changes:
- Made sbom conditional: only enabled for push events (not PRs)
- Made provenance conditional: only enabled for push events (not PRs)
- PRs now build without attestations (faster, avoids manifest list error)
- Production pushes still get full SBOM and provenance attestations
This allows:
- PR builds to complete successfully with load=true
- Production builds to maintain supply chain security features
Fixed critical workflow issues preventing builds:
1. Job Dependency Structure:
- build-and-push now properly depends on security-check with always()
- Allows push/tag events to run even when security-check is skipped
- Only pull_request events trigger security-check
- Conditional logic checks needs.security-check.result to handle skipped cases
2. Platform vs Load Conflict:
- Removed platform specification for PR builds (load=true)
- load: true only works with single platform matching host
- Multi-platform (linux/amd64,linux/arm64) only for push events
- Empty string for platforms when using load to avoid conflicts
3. Conditional Logic Improvements:
- push events: always run (security-check skipped)
- workflow_dispatch: always run (security-check skipped)
- pull_request: only run if security-check succeeded and not a fork
- pull_request_target: only run if has 'safe-to-build' label
This ensures:
- Branch pushes work correctly
- Tag builds work correctly
- PRs are security-checked before building
- Fork PRs require manual approval
Fixed two critical build failures:
1. Platform Selection Bug:
- Fixed operator precedence issue in platform conditional
- Was evaluating to boolean 'true' instead of platform string
- Changed: platforms: ${{ ... || ... && 'linux/amd64' || ... }}
- To: platforms: ${{ (... || ...) && 'linux/amd64' || ... }}
- Now correctly uses linux/amd64 for PRs, linux/amd64,linux/arm64 for releases
2. Trivy Multiple Tags Issue:
- Trivy was receiving multiple tags separated by newlines
- Added step to extract first tag from metadata output
- Trivy now scans using single tag reference
- Prevents "multiple targets cannot be specified" error
Both PRs and production builds should now complete successfully.
Changed from SHA-pinned actions to version tags (e.g., @v3, @v4, @v5)
for easier maintenance and automatic security updates via Dependabot.
While SHA pinning provides slightly better supply chain security, version
tags with Dependabot updates provide a better balance of security and
maintainability for most projects.
Updated actions:
- actions/checkout@v4
- docker/setup-buildx-action@v3
- docker/login-action@v3
- docker/metadata-action@v5
- docker/build-push-action@v5
- aquasecurity/trivy-action@0.24.0
- github/codeql-action/upload-sarif@v3
Dependabot will automatically create PRs for security updates.
Security Improvements:
- Fork PR Protection: Builds from forks require manual 'safe-to-build' label approval
- Trivy Vulnerability Scanning: Scan all images for CRITICAL/HIGH vulnerabilities
- SHA-Pinned Actions: All GitHub Actions pinned to specific commits for supply chain security
- SBOM Generation: Generate Software Bill of Materials for all builds
- Provenance Attestation: Record build provenance for supply chain verification
- Security Events Upload: Upload scan results to GitHub Security tab
- Platform Optimization: Single-platform builds for PRs for faster feedback
Additional Security:
- Created SECURITY.md with vulnerability reporting process and security practices
- Added Dependabot configuration for automated dependency updates
- Limited permissions model (contents:read, packages:write, security-events:write)
- No registry push from PR builds (load-only for security scanning)
This addresses concerns about malicious PR builds by:
1. Requiring manual approval for fork PRs
2. Scanning all images before they could be pushed
3. Preventing PR builds from pushing to registry
4. Using verified, SHA-pinned actions
Remove the prefix={{branch}}- from the sha tag type which was causing
invalid tag formats like ":-cbc2c2c" when building pull requests.
The {{branch}} placeholder becomes empty for PRs, leaving only the dash
prefix which creates an invalid Docker tag.
Changed from: type=sha,prefix={{branch}}-
Changed to: type=sha
This generates valid tags like "sha-cbc2c2c" for all events.
Following Prisma's official documentation for deployment caching issues:
https://www.prisma.io/docs/orm/more/help-and-troubleshooting/vercel-caching-issue
Changes:
- Add 'prisma generate' to build script (official Prisma recommendation)
- Add postinstall script for automatic client generation
- Remove custom stub generator workaround
- Keep runtime Prisma client generation in entrypoint.sh for reliability
- Add openssl to runtime container (required for Prisma engines)
This follows Prisma best practices: explicitly run prisma generate during the
build process to ensure Prisma Client is always up-to-date. The entrypoint
script regenerates the client at runtime to guarantee engine availability in
the production environment.
Previously, proxy hosts with "Managed by Caddy (Auto)" (certificate_id = null)
were being skipped during Caddy configuration generation, causing the feature
to not work at all.
This commit adds full support for automatic certificate management:
1. Modified collectCertificateUsage() to track domains with null certificate_id
separately as auto-managed domains
2. Updated buildTlsAutomation() to create ACME automation policies for
auto-managed domains (supports both HTTP-01 and DNS-01 challenges)
3. Modified buildTlsConnectionPolicies() to include TLS connection policies
for auto-managed domains
4. Updated buildProxyRoutes() to allow proxy hosts with null certificate_id
to be included in the route configuration
The configuration now automatically updates when domains are changed, as
applyCaddyConfig() is already called on create/update/delete operations.
Caddy will now automatically obtain and manage Let's Encrypt certificates
for all domains when "Managed by Caddy (Auto)" is selected.
This commit resolves multiple build errors and adds a workaround for environments
where Prisma engine binaries cannot be downloaded due to network restrictions.
Changes:
- Fix TypeScript error: Remove invalid request.ip property access in NextAuth route
- Add missing config import in auth.ts for sessionSecret
- Add dynamic = 'force-dynamic' to API routes to prevent static generation
- Create Prisma stub generator script for build-time type checking
- Update build script to use stub generator instead of prisma generate
- Add binaryTargets to Prisma schema configuration
The stub generator allows the Next.js build to complete successfully in environments
where Prisma binaries cannot be downloaded (403 Forbidden errors from binaries server).
The actual Prisma engines will need to be available at runtime in production deployments.
All routes are now properly configured as dynamic server-rendered routes.
This commit addresses several critical security issues identified in the security audit:
1. Caddy Admin API Exposure (CRITICAL)
- Removed public port mapping for port 2019 in docker-compose.yml
- Admin API now only accessible via internal Docker network
- Web UI can still access it via http://caddy:2019 internally
- Prevents unauthorized access to Caddy configuration API
2. IP Spoofing in Rate Limiting (CRITICAL)
- Updated getClientIp() to use Next.js request.ip property
- This provides the actual client IP instead of trusting X-Forwarded-For header
- Prevents attackers from bypassing rate limiting by spoofing headers
- Fallback to headers only in development environments
3. Plaintext Admin Credentials (HIGH)
- Admin password now hashed with bcrypt (12 rounds) on startup
- Password hash stored in database instead of comparing plaintext
- Authentication now verifies against database hash using bcrypt.compareSync()
- Improves security by not storing plaintext passwords in memory
- Password updates handled on every startup to support env var changes
Files modified:
- docker-compose.yml: Removed port 2019 public exposure
- app/api/auth/[...nextauth]/route.ts: Use actual client IP for rate limiting
- src/lib/auth.ts: Verify passwords against database hashes
- src/lib/init-db.ts: Hash and store admin password on startup
Security posture improved from C+ to B+
- Add router.refresh() to proxy-hosts and redirects dialogs
- Auto-close dialogs 1 second after successful form submission
- Fixes stale data not refreshing after create/edit/delete operations
- Fixes localhost redirect issues (requires BASE_URL env var to be set)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Previously, upstream URLs like 'https://iot2.fuo.fi' were passed directly
to Caddy's dial field, causing DNS lookup errors like 'lookup /iot2.fuo.fi'.
Changes:
- Parse upstream URLs to extract hostname:port for Caddy's dial field
- Automatically detect HTTPS upstreams and configure TLS transport
- Support insecure_skip_verify flag for self-signed certificates
- Default to port 443 for https://, port 80 for http://
Fixes: 'dial tcp: lookup /host: no such host' errors when using URL
format for upstreams instead of host:port format.
Previously, managed certificates required Cloudflare DNS to be configured,
otherwise no TLS automation was configured and HTTPS would fail with TLS
handshake errors.
Changes:
- When Cloudflare is configured: use DNS-01 challenge via Cloudflare
- When Cloudflare is NOT configured: use HTTP-01 challenge (default)
- Enable automatic HTTPS when TLS automation policies exist
- This allows Let's Encrypt certificates via HTTP-01 challenge
Fixes TLS handshake errors when using managed certificates without
Cloudflare configuration. Port 80 must be accessible for HTTP-01.
When POSTing config to /load, Caddy was resetting the admin endpoint
from 0.0.0.0:2019 to localhost:2019, making it inaccessible from the
web container.
Now explicitly include admin config in the generated JSON to ensure
the admin API remains accessible at 0.0.0.0:2019 after config reloads.
Fixes ECONNREFUSED errors when applying Caddy config after the first load.
The caddy-dns/cloudflare module only accepts api_token.
Both zone_id and account_id fields are not supported and cause config errors.
The provider automatically handles all zones accessible by the API token.
Fixes: 'unknown field zone_id' error when applying Caddy config.
The caddy-dns/cloudflare module only supports api_token and zone_id fields.
The account_id field was causing config load errors: 'unknown field account_id'.
Fixes Caddy config validation error when using Cloudflare DNS for ACME challenges.
The issue occurred because the auth system uses a hardcoded JWT user ID (1)
that didn't exist in the database, causing foreign key constraint violations
when creating proxy hosts.
Changes:
- Added init-db.ts to ensure admin user exists in database
- Added instrumentation.ts to run DB initialization on server startup
- Admin user (from ADMIN_USERNAME env var) is now created with ID 1
- Matches the hardcoded ID in auth.ts for JWT tokens
Fixes foreign key constraint error (P2003) when creating proxy hosts.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
