- Removed trianglify dependency (which required Node.js canvas)
- Implemented custom gradient mesh using HTML5 Canvas API
- Browser-native solution works in Docker without native dependencies
- Maintains daily variation and theme color support
- No more 'i.from is not a function' errors
Added echo statements and --loglevel=verbose to see exactly what npm is
doing during the long ARM64 build process. This will help diagnose why
it's taking so long under QEMU emulation.
Canvas requires native build tools to compile:
- python3: For node-gyp
- make, g++, pkgconfig: C++ compiler and build tools
- cairo-dev, jpeg-dev, pango-dev, giflib-dev: Native libraries
By installing these dependencies before npm install, canvas can properly
build its native bindings for both AMD64 and ARM64 architectures.
Removed try-catch blocks around trianglify since it should now work properly.
Canvas requires Python and native build tools which fail in Docker builds
with --ignore-scripts. Since trianglify is only used for cosmetic backgrounds
on the login and layout pages, we can make it optional.
Changes:
- Added try-catch around trianglify usage in Login and Layout
- Using --ignore-scripts in frontend Dockerfile to skip canvas native build
- Gracefully fail when trianglify is not available (background won't render)
This allows the frontend to build and run even without canvas/trianglify.
The 'i.from is not a function' error occurs because trianglify depends
on canvas, and --ignore-scripts prevented canvas from installing properly.
Solution: Remove --ignore-scripts and allow npm to run install scripts,
but gracefully handle canvas rebuild failures since native bindings
are optional for the production build.
ARM64 builds under QEMU are slower and more prone to network timeouts.
Changed from --fetch-retries=0 to --fetch-retries=3 with exponential backoff:
- Min timeout: 20 seconds
- Max timeout: 120 seconds
This should handle transient ECONNRESET errors from npm registry.
Vite is in devDependencies and is required to build the frontend.
Using --omit=dev skipped it, causing 'vite: not found' error.
Build dependencies are needed during the builder stage, they won't be
included in the final production image since we copy only the built
artifacts (dist/) to the nginx image.
The trianglify package depends on canvas, which tries to build native binaries
requiring Python and build tools. Since canvas is not actually needed for the
browser build (trianglify uses it only server-side), we can skip all install
scripts with --ignore-scripts to avoid the build failure.
This fixes the ARM64 and AMD64 frontend builds.
The frontend subdirectory doesn't have its own package-lock.json (only at
workspace root), so npm ci fails. Using npm install instead to generate
dependencies from package.json.
The previous approach installed workspace root dependencies which included
backend packages like 'canvas' that require native build tools (Python, gcc).
Changes:
- Work directly in /app/frontend instead of /app root
- Copy only frontend/package*.json (not root package.json)
- Run 'npm run build' instead of 'npm run build:frontend'
- This installs only frontend dependencies (Vite, React, etc.)
This avoids attempting to build unnecessary backend dependencies in the
frontend Docker image.
Removed --ignore-scripts flag and added cache cleanup to ensure optional
dependencies like @rollup/rollup-linux-arm64-musl are properly installed.
This mirrors the fix applied to the backend Dockerfile for ARM64 support.
The workspace package-lock.json had corrupted 'resolved' URLs for many packages
including string_decoder, causing Docker builds to fail with 404 errors.
Changes:
- Regenerated root package-lock.json which manages all workspace dependencies
- Restored npm ci in Dockerfile (now that lockfile is fixed)
- Keep PRISMA_CLI_BINARY_TYPE=binary for ARM64 compatibility
This should resolve both AMD64 and ARM64 Docker build failures.
- Delete package-lock.json in Docker build to avoid corrupted string_decoder entry
- Use npm install instead of npm ci to regenerate package-lock.json fresh
- This avoids the 'string_decoder is a core module' error that package-lock.json had cached
- Added --prefer-online flag to npm ci to bypass corrupted cache
- Set --fetch-retries=0 to fail fast on corrupted packages
- Removed /root/.npm directory as well to clear all caches
- Fixed typo in workflow name
- Re-enabled linux/arm64 platform builds
- Added PRISMA_CLI_BINARY_TYPE=binary to use pre-compiled binaries
- This avoids native compilation issues under QEMU emulation
- Use npm script for Prisma generation instead of npx
ARM64 builds were failing with 'Illegal instruction' errors during npm ci
due to QEMU emulation issues. Since PatchMon is a Node.js application,
AMD64 images will run fine on ARM64 systems (like Apple Silicon Macs)
using Rosetta emulation. This simplifies the build process.
The get-intrinsic package tarball is getting corrupted in the npm cache.
By removing ~/.npm entirely and fetching fresh packages, we avoid the
corrupted cache issue that's causing the string_decoder error.
The string_decoder error occurs when npm tries to install it as a separate package
when it's actually a Node.js core module. Using --legacy-peer-deps helps resolve
this peer dependency conflict during Docker builds.
- Remove unused imports and variables in metricsRoutes.js
- Prefix unused error variables with underscore
- Fix useEffect dependency in Login.jsx
- Add aria-label and title to all SVG elements for accessibility
Added DB_IDLE_TIMEOUT and DB_MAX_LIFETIME to both production and dev Docker Compose files to complete the connection pool configuration. These variables were already documented but missing from the compose files.
- Replace individual queries per package with batch GROUP BY queries
- Reduces from potentially hundreds of queries to just 3 queries total
- Creates lookup maps for O(1) access when assembling results
- Improves packages page loading time significantly
- Replace persistent SSE connections with lightweight polling (10s interval)
- Optimize WebSocket status fetching using bulk endpoint instead of N individual calls
- Fix N+1 query problem in /dashboard/hosts endpoint (39 queries → 4 queries)
- Increase database connection pool limit from 5 to 50 via environment variables
- Increase Axios timeout from 10s to 30s for complex operations
- Fix malformed WebSocket routes causing 404 on bulk status endpoint
Fixes timeout issues when adding hosts with multiple WebSocket agents connected.
Reduces database connections from 19 persistent SSE + retries to 1 poll every 10 seconds.
This script fixes the HTTP connection limit issue by adding a bulk status endpoint to the backend and updating the frontend to utilize this endpoint. Backups of the modified files are created before changes are applied.
This script updates hardcoded connection pool values in prisma.js, allowing for customizable connection settings through command-line arguments. It also creates a backup of the original file before applying changes.
