* fix: strip credentials from service-level API responses
Registry passwords and S3 destination credentials were being returned
in service `.one` tRPC endpoints to any user with service-level read
access. Reported by Nihon Kohden Corporation security team.
- Strip registry `password` from `findApplicationById` via Drizzle `columns: { password: false }`
- Strip destination `accessKey`/`secretAccessKey` from all DB service finders (postgres, mysql, mariadb, mongo, libsql, compose, backup, volume-backups)
- Add `findRegistryByIdWithCredentials` for internal use only
- Builders and upload utils now load registry credentials by ID at execution time
- `createRollback` enriches `fullContext` with registry credentials before persisting to DB so rollback execution has what it needs
- Remove `findApplicationByIdWithCredentials` and `ApplicationNestedWithCredentials` — no longer needed
- Backup execution utils load full destination via `findDestinationById` at runtime instead of reading from the joined relation
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
- Updated the mechanizeDockerContainer function to conditionally use authConfig when creating a Docker service, ensuring proper service creation based on authentication settings.
Users deploying to Docker Swarm can now configure resource ulimits
(nofile, nproc, etc.) to prevent applications from hitting system
limits that cause crashes or degraded performance.
- Added a new optional field `rollbackRegistryId` to the application schema to support rollback registry selection.
- Enhanced the form in the ShowRollbackSettings component to include a dropdown for selecting a rollback registry when rollbacks are enabled.
- Updated the application service to handle rollback registry logic during deployment and rollback processes.
- Improved error handling and validation for rollback settings, ensuring a registry is selected when rollbacks are active.
- Adjusted database schema and migration files to accommodate the new rollback registry feature.
- Updated the application, mariadb, mongo, mysql, postgres, and redis schemas to include an optional `args` field for command arguments.
- Enhanced the AddCommand and ShowCustomCommand components to handle multiple arguments using a dynamic form.
- Modified the database build functions to incorporate the new `args` parameter when creating containers.
- Added SQL migrations to update the database schema for existing applications and services to accommodate the new `args` field.
- Added support for build server configuration in the application dashboard, including new UI elements and validation.
- Updated database schema to include build server associations and foreign key constraints.
- Enhanced deployment logic to utilize build server IDs, improving deployment flexibility.
- Improved logging and user feedback during the build and deployment processes, including new alerts for image download status.
- Refactored application and deployment services to accommodate build server integration.
- Updated the condition for StopGracePeriod in various database builder files to check for null and undefined values, improving code robustness and clarity.
- Updated the handling of StopGracePeriod in various database builders to streamline the condition check, improving code readability and maintainability.
- Updated the rollbacks schema to include mounts, ports, and optional registry information in the full context.
- Refactored the rollback service to utilize the full context for improved rollback operations, ensuring all necessary configurations are applied.
- Exported the getAuthConfig function for better accessibility in the application context.
- Updated the logic for constructing the registry tag in the uploadImage and uploadImageRemoteCommand functions to ensure correct formatting.
- Removed unnecessary path imports and streamlined the code for better readability.
- Removed unnecessary console logging in the mechanizeDockerContainer function to enhance code clarity.
- Simplified error handling by directly creating a new service if the existing one is not found, improving the deployment logic.
- Updated the buildNixpacks function to ensure container cleanup is attempted without additional error handling, streamlining the process.
- Introduce Railpack as a new build method for applications
- Update database schema to include 'railpack' in buildType enum
- Add Railpack installation and validation scripts for servers
- Implement Railpack build and command generation utilities
- Update UI to include Railpack as a build option with a 'New' badge
This commit focuses on removing unused variables, adding placeholder error handling, and generally tidying up various files across the Dokploy application. Changes include:
- Removing unused imports and variables
- Adding placeholder error handling in catch blocks
- Cleaning up commented-out code
- Removing deprecated utility files
- Improving type safety and code consistency
