Add deployment removal and drained deployment pruning to ServiceDeployer

[pcholakov]

Add automatic pruning of drained deployments

Adds optional automatic cleanup of old deployment versions that accumulate as services are re-registered over time.

Changes

• Pruning drained deployments: New pruneDrainedDeployments option automatically removes deployments with no associated services and no pinned invocations after each successful registration
• Revision history control: revisionHistoryLimit parameter allows keeping N most recent drained deployments
• Invocation filtering: allowPruningDeploymentsWithCompletedInvocations controls whether deployments with only completed invocations can be pruned (conservative by default)
• Query endpoint integration: Added support for querying Restate's SQL API to identify prunable deployments (fixed Accept header for JSON format)

Usage Example

deployer.register(handler.currentVersion, environment, {
  pruneDrainedDeployments: true,
  revisionHistoryLimit: 3,  // retain 3 most recent deployments, even if drained
});

Testing

• new E2E test (ec2-pruning-test.e2e.ts) validates pruning behavior with real AWS infrastructure:
  • Deploys Lambda service handler (v1) to EC2-hosted Restate
  • Verifies initial deployment exists
  • Re-deploys with new version (v2) triggering re-registration
  • Confirms old deployment was pruned (only new deployment remains)
  • Test passes with aggressive pruning enabled

Summary of All E2E Test Results

✅ Single Node EC2 Test (311.6s)

• Deployed Restate on EC2
• Successfully invoked Greeter service
• Stack retained due to RETAIN_STACK

✅ Drained Deployment Pruning Test (373.8s)

• Initial deployment verified
• Re-deployed with new configuration version
• Confirmed old drained deployment was pruned
• Stack retained

✅ Restate Cloud Lambda Test (84.5s)

• Deployed Lambda to Restate Cloud EU
• Successfully invoked Greeter service
• Stack retained due to RETAIN_STACK

---

Fixes #5, #82

[jackkleeman]

given that invocation id formatting is oddly expensive, we could maybe avoid ever reading the inv id:

const sql = `
  SELECT d.id, d.created_at
  FROM sys_deployment d
  WHERE NOT EXISTS (
    SELECT 1 FROM sys_service s WHERE s.deployment_id = d.id
  )
  AND NOT EXISTS (
    SELECT 1 FROM sys_invocation_status i 
    WHERE i.pinned_deployment_id = d.id ${invocationStatusFilter}
  )
  ORDER BY d.created_at DESC
  OFFSET ${safeOffset}
  LIMIT ${safeLimit}
`;

i may look to do similar things in the operator

[pcholakov]

nice! 😁

[jackkleeman]

i feel like it should be ASC? so we get the oldest ones

[pcholakov]

It should be, I was counting on OFFSET here to skip the first N "protected" deployments; came up with something way nicer along with your id trick above.

[jackkleeman]

as discussed in dm, i dont think we need this

[pcholakov]

Ended up resorting to using the API, which gives us extra service name information that we can map back to our current deployment. Unfortunately the sys_deployment schema doesn't list services, which makes it impossible to query only the relevant fully drained deployments for the service(s) which the service deployer is managing. I've opened restatedev/restate#4316 which would make this much more straightforward.

[pcholakov]

I'm sorry @jackkleeman, ended up completely changing course here - I couldn't implement the query I wanted to so ended up resorting to calling the REST API + DF for drained status. Inelegant but much safer, I don't want to risk pruning deployments from services that aren't managed by the CDK service deployer.