Your service uses SIP registrations and WebSocket connections to external servers, and attaching a volume disables zero-downtime deployments per our volumes documentation - meaning every deploy causes brief downtime since multiple deployments cannot be active simultaneously when a volume is mounted. This downtime would drop all active SIP registrations, WebRTC sessions, and WebSocket connections. Additionally, volumes are not mounted as overlays, so if your mount path overlaps with any existing application directory (e.g., mounting at /app or a subdirectory containing app files), the volume will replace those files with an empty directory, which could make the service non-functional. Could you share the mount path you configured for the volume?

We used /app/uploads . We are needing this to store call recordings. Is. this possible without breaking anything?

Mounting at /app/uploads is the correct path for your use case and should not overwrite any application files. The disruption you experienced is expected behavior: attaching a volume triggers a redeployment, and services with volumes cannot have zero-downtime deployments, so there is brief downtime during each deploy that drops active SIP registrations and WebSocket connections. Your current logs show the SIP status as registered and healthy, so the service does recover after the deploy completes - the outage is temporary, not permanent.

You would think so I did this last night, went to sleep woke up 5 hours later tried again and everything was down. I had to change it back disconnect it before my clients woke up so they would not be disrupted. any ideas?

Hello,

This may happen when your service has a volume, and since two deployments can not be mounted to the same volume at the same time, we must stop the previous deployment before starting the new deployment. This has always been the logic since we first introduced support for volumes.

Users have worked around this by offloading storage to a separate service such as MinIO so that their main application will not need a volume and thus is not subject to the mandatory downtime.

That makes sense but my problem was complete loss of outbound networking — no external API calls working at all, for hours, across multiple rollbacks. I will look into external options though.

That does sound like more than typical deploy downtime. We can see your service is currently healthy with outbound networking working fine, but we don't have network telemetry from last night's volume attachment to confirm what caused the prolonged outage. If you'd like to try attaching the volume again, let us know before you do and we can monitor the networking in real-time to determine whether it's a platform-side issue. In the meantime, using a separate service with a volume (like MinIO) for storing recordings is the most reliable path since it keeps your main SIP service free of the volume constraint.

I decided to go with AWS connected route as it seems to be a safer route can't afford downtime with clients. Thanks.

Sounds good, glad you found a path forward. Let us know if you need anything else.