🚀 Release v0.28.5

[github-actions]

This PR promotes changes from canary to main for version v0.28.5.

🔍 Changes Include:

• Version bump to v0.28.5
• All changes from canary branch

✅ Pre-merge Checklist:

• All tests passing
• Documentation updated
• Docker images built and tested

🤖 This PR was automatically generated by GitHub Actions

Greptile Summary

This release (v0.28.5) contains a broad set of fixes and improvements. However, three significant issues require attention before merging:

1. Deployment cleanup can block deployment creation (critical): The removeLastTenDeployments function is called outside the try/catch in all createDeployment* functions. The execAsyncRemote call within it (for remote servers) is not guarded by try/catch, so transient network failures during old-log cleanup will propagate and prevent the new deployment from starting with no error log recorded.

2. Breaking S3 backup path change (high impact): All backup types now write to appName/prefix/filename instead of prefix/filename. Existing backups remain at the old path and will no longer be discovered or pruned by keepLatestNBackups. Users upgrading will silently accumulate orphaned backups at the old S3 paths.

3. MongoDB restore is now destructive (data loss risk): The --drop flag was added to mongorestore, meaning each collection is dropped before being restored. This changes behavior from the previous additive restore — users may not expect this and could unintentionally lose data.

Other changes (GitHub OAuth state encoding, Azure AI URL fix, CodeMirror search, Swarm overlay network fix, YAML maxAliasCount increase) appear well-implemented.

Confidence Score: 2/5

• This PR introduces a logic bug that can silently break deployment creation on remote servers, and two breaking changes (S3 backup paths and MongoDB restore behavior) that will affect existing users.
• The uncaught exception in removeLastTenDeployments is a critical bug that can cause deployment creation to fail silently when remote log cleanup encounters network issues. The S3 backup path change is a breaking change that will cause all existing S3 backups to become orphaned and no longer be automatically cleaned up. The MongoDB --drop flag change alters restore behavior to be destructive, risking data loss for users who don't expect this. These three issues affect core reliability and data safety.
• packages/server/src/services/deployment.ts (uncaught error path), packages/server/src/utils/backups/* (all backup files affected by breaking path change), packages/server/src/utils/restore/utils.ts (destructive restore behavior)

_{Last reviewed commit: ec7df05}

Greptile also left 3 inline comments on this PR.

[greptile-apps]

Uncaught execAsyncRemote can cause deployment creation to fail

execAsyncRemote(serverId, command) is not wrapped in a try/catch. Individual deployment cleanup errors are caught (lines 687-702), but this batched remote command — which runs after those loops — is not. If the remote server is unreachable or returns an error here, the exception will propagate up through removeLastTenDeployments.

This becomes a critical problem because removeLastTenDeployments is now called outside the try block in all of createDeployment, createDeploymentPreview, createDeploymentCompose, etc. A network hiccup during log cleanup would cause the entire deployment creation to fail without creating an error deployment log entry, leaving the caller with an unhandled TRPCError.

Consider wrapping this in a try/catch:

Suggested change

	if (command) {
	await execAsyncRemote(serverId, command);
	}
	if (command) {
	try {
	await execAsyncRemote(serverId, command);
	} catch (err) {
	console.error("Failed to delete old remote log files during cleanup:", err);
	}
	}

[greptile-apps]

Breaking change: S3 backup path structure is not backward-compatible

The S3 backup destination path has changed from prefix/filename.sql.gz to appName/prefix/filename.sql.gz. This is a breaking change for existing users who already have backups stored in S3:

• Existing backups remain at the old path (prefix/filename.sql.gz)
• New backups are written to the new path (appName/prefix/filename.sql.gz)
• The keepLatestNBackups cleanup routine now scans the new path exclusively, so it will never find or prune the old backups — they will accumulate indefinitely
• Any user-configured restore jobs pointing to the old path would break silently

The same path change applies across all backup types: mariadb.ts, mongo.ts, mysql.ts, postgres.ts, web-server.ts, compose.ts, volume-backups/backup.ts, and volume-backups/utils.ts.

A migration guide or at least a clear note in the release notes would help users understand that their old backups are now at a different path and they should manage them manually or relocate them.

[greptile-apps]

Behavioral change: --drop drops existing collections before restoring

The --drop flag tells mongorestore to drop each collection before restoring it. This is a destructive operation — any data in the target collections that was not part of the backup will be permanently deleted.

Previously, mongorestore ran in additive mode: documents from the backup were inserted, but existing documents in the database were left untouched. With --drop, a restore now fully replaces each collection.

While this may be the intended behavior for a clean restore, users upgrading from an earlier version may not expect this change and could unintentionally destroy data. Consider documenting this change prominently in the release notes.