* feat: add memory limits to docker-compose files for self-hosted deployments Add resource limits to all docker-compose configurations to prevent unbounded memory growth and improve stability on resource-constrained self-hosted deployments. Memory limits are based on the existing Coolify deployment configuration: - libsql: 512M limit / 256M reservation - tinybird-local: 1G limit / 512M reservation - workflows: 512M limit / 256M reservation - server: 512M limit / 256M reservation - private-location: 256M limit / 128M reservation - checker: 256M limit / 128M reservation - dashboard: 512M limit / 256M reservation - status-page: 512M limit / 256M reservation Total limits: ~4.1GB (suitable for 8GB RAM systems with headroom) This prevents swap thrashing and improves OOM handling on systems with limited memory, addressing issues where LibSQL connection timeouts occur due to severe memory pressure. Files modified: - docker-compose.yaml - docker-compose.github-packages.yaml - docker-compose-lightweight.yaml * fix: add memswap_limit to prevent swap usage in docker-compose files Docker's default behavior sets memory-swap to 2x the memory limit when only memory is specified. This means a container with memory: 512M can actually use 512M RAM + 512M swap = 1GB total, defeating the purpose of memory limits for preventing swap thrashing. This commit adds memswap_limit equal to the memory limit for all services, ensuring containers cannot use ANY swap space. This truly prevents the swap thrashing issue that was causing LibSQL 429 errors. Changes: - docker-compose.yaml: Added memswap_limit to 7 services - docker-compose.github-packages.yaml: Added memswap_limit to 8 services - docker-compose-lightweight.yaml: Added memswap_limit to 3 services Total memory allocation remains unchanged at ~4.1GB, but now enforces RAM-only usage without swap. * fix: remove Tinybird memory limits that prevented functionality * feat: add CPU and connection limits to LibSQL to prevent resource exhaustion - Add CPU limits: 2.0 cores max, 1.0 core reserved - Add connection limits: max 100 concurrent connections - Add request limits: max 10 concurrent requests per connection - Add idle timeout: 300s to clean up stale connections Fixes progressive CPU degradation where LibSQL would spike to 358% CPU and return 429 errors for all requests until restart. * fix: increase LibSQL limits and fix connection leaks in backfill scripts - Increase SQLD_MAX_CONCURRENT_CONNECTIONS to 512 (from default 128) - Increase SQLD_MAX_CONCURRENT_REQUESTS to 1024 (from default 128) - Set LibSQL CPU limit to 4.0 cores with 2.0 reservation - Fix connection leak in backfill_external_status_v0_to_v1.ts by adding client.close() Addresses LibSQL 429 errors under concurrent load from multiple services * chore: remove CPU limits from libsql service Keep SQLD_MAX_CONCURRENT_CONNECTIONS=512 and SQLD_MAX_CONCURRENT_REQUESTS=1024 but remove CPU core limits to allow LibSQL to use available CPU resources without artificial constraints * ci: apply automated fixes * fix: add SQLD connection limits to github-packages compose file --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>