Custom deployment strategies

Phoenix
5

I’m also looking into a custom deploy strategy, which has 2 goals

  1. more extensive tests in real life infra, including 6pn
  2. keeping old scaled to 0 deploys around for “skew protection”

Let’s say we have app with name foo, which has custom domains, certs, dns and everything set up

Ideally, I think, it’d be amazing to be able to deploy to a randomly generated app name bar, do some testing etc, then basically move all the traffic from foo over to bar while having some internal mapping of git versions to deployment names/ids so that if bar receives a request which originated from a foo front-end it can replay the request to foo via the replay header, which should boot up the possibly already scaled to 0 app foo. So I think this might require something like renaming an existing and running app which doesn’t seem to be possible from what I read

As the app already needs inter instance/app communication to forward websocket traffic etc it’d be nice to do the same in this scenario, though from what I gathered so far this might not really be possible at the moment? Tho pleease correct me if I’m wrong :crossed_fingers:

The alternative I can think of which I probably like to avoid would be a separate api-gateway app which needs less (potentially breaking) deploys and just orchestrates where to proxy the incoming request to, which would make all the domain & dns stuff be stable and the name of the actual app wouldn’t matter to the outside world, this might also be helpful with the custom user domains part

Another one might be programmatically changing DNS records to move traffic from foo over to bar

Also note we plan on supporting custom user domains soonish which I don’t have the definitive setup we’re going for fleshed out yet, might be purely on fly or via a cdn in front, was looking into bunny or potentially cloudfront as alternative, cloudflare seems to be a bit pricey for this use-case. The custom domain thing makes me think that the last option, updating dns records might be a little less convenient overall and potentially everything leads to a separate api-gateway app in front :thinking: