When editing a proxy host with certificate_id set to null (auto), the
dropdown would not show "Managed by Caddy (Auto)" as selected and it
would revert to another certificate. There were two issues:
1. Form submission: Empty string from dropdown was treated as falsy,
returning undefined instead of null (means "don't change")
2. Database update: The ?? operator treated null as falsy and fell back
to existing value instead of saving null
Changes:
- app/(dashboard)/proxy-hosts/actions.ts: Check formData.has() and
explicitly convert empty string to null for auto mode
- src/lib/models/proxy-hosts.ts: Use !== undefined instead of ?? to
allow null values to be saved
- app/(dashboard)/proxy-hosts/ProxyHostsClient.tsx: Add Certificate
column to table showing "Managed by Caddy (Auto)" for auto certs
Applied same fixes to access_list_id for consistency.
Now when users select "Managed by Caddy (Auto)", it correctly sets
certificate_id to null, displays properly on subsequent edits, and
shows in the table view.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
When editing a proxy host with certificate_id set to null (auto), the
dropdown would not show "Managed by Caddy (Auto)" as selected. The issue
was that empty string from the dropdown was treated as falsy, returning
undefined instead of null, which means "don't change" in the update logic.
Changes:
- Check if certificate_id field exists with formData.has()
- Explicitly convert empty string to null for auto mode
- Apply same fix to access_list_id for consistency
Now when users select "Managed by Caddy (Auto)", it correctly sets
certificate_id to null and displays properly on subsequent edits.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The forward_auth directive only exists in Caddyfile syntax, not JSON config.
This fix converts Authentik authentication to use the underlying reverse_proxy
handler with proper configuration:
- Replace forward_auth handler with reverse_proxy
- Convert "private_ranges" keyword to actual CIDR blocks for JSON config
- Parse upstream URL to extract host:port for dial field (removing http://)
- Add handle_response block to copy Authentik headers on 2xx status
- Preserve X-Forwarded-Method and X-Forwarded-Uri headers
Fixes error: "unknown module: http.handlers.forward_auth"
Fixes error: "invalid IP address: 'private_ranges'"
Fixes error: "lookup /hostname: no such host" (dial with URL scheme)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Following the Prisma guide for GitHub Actions and CI/CD, this commit addresses
the Prisma client generation issues in the Docker build process:
Changes:
1. **package.json**:
- Removed silent failure fallback in postinstall hook
- Removed redundant prisma generate from build script
- Now fails fast if Prisma generation has issues
2. **docker/web/Dockerfile**:
- Added DATABASE_URL environment variable in deps stage
- Explicitly run prisma generate after npm install to ensure client is created
- Generate Prisma client again in builder stage for build context
- Removed --skip-generate flag from prisma db push
- Added clear comments explaining each Prisma-related step
These changes ensure:
- Prisma client is generated with correct engines for debian-openssl-3.0.x
- Build fails early if there are Prisma configuration issues
- DATABASE_URL is set before running any Prisma commands
- Proper multi-stage Docker build with Prisma support
The previous attempt failed because Prisma CLI couldn't parse the binaryTarget
configuration due to an incorrect environment variable I set. This commit:
- Removes the non-existent PRISMA_CLI_BINARY_TARGETS environment variable
- Copies the Prisma schema BEFORE running npm ci, allowing the postinstall
script to properly generate the Prisma client with engines
- Adds openssl and ca-certificates to deps stage for engine downloads
- Simplifies the builder stage to rely on pre-generated engines from deps
This ensures Prisma engines are downloaded during npm installation via the
postinstall hook, making them available for subsequent build steps.
The build was failing with Prisma schema validation errors because Prisma
couldn't download engine binaries from binaries.prisma.sh (403 Forbidden).
This resulted in cryptic parsing errors during 'prisma generate'.
Changes:
- Add openssl and ca-certificates to deps stage for engine downloads
- Set PRISMA_ENGINES_CHECKSUM_IGNORE_MISSING to bypass checksum validation
- Pre-generate Prisma client with engines in deps stage
- Copy pre-generated client to builder stage to avoid re-downloading
- Set PRISMA_SKIP_POSTINSTALL_GENERATE in builder to prevent regeneration
This ensures engines are bundled during the deps stage and reused in
subsequent stages, eliminating network dependency during the build phase.
The build was failing during 'prisma generate' with numerous validation
errors because Prisma's query engine requires OpenSSL to function properly.
The builder stage was missing the openssl package, causing the engine to
fail to load and produce cryptic parsing errors.
This adds openssl installation to the builder stage, matching what was
already present in the runner stage.
- Remove /app/node_modules/.prisma/client before generating
- Prevents EACCES errors when Prisma tries to unlink existing files
- Cleanup runs as root before switching to nextjs user
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.
