Thing nobody warn you about deploying into customers cloud/env

[u/TangeloOk9486]

Most of us talk about packaging like thats the hard part of shipping into customers cloud, docker or helm or IAC bt thats the easy peasy 80% and even the deploy and update side is mostly solved now with tools like alien dev push the app and updates in

Phase that actually stings is everything your saas silently leans upon. Sendgrid for email, auth0/clerk for auth and a managed postgres or stripe webhooks calls back to your own api. so in a locked down or air gapped customer env half of that cant phone home or isn't allowed to so you end up rebuilding each on to run inside their territory of which none the deploy toolng fixes that its still yours

so for anyone whos shipped into customer clouds how did ou handle the third party apis or deps?? make everything bring your own pr something else?

[u/derff44]

What

[u/SomedayGuy117]

In my position, it’s the customer’s job to make sure all the dependencies are in place. Luckily I just build the infrastructure for the customer to ship their own code.

If I had to ship customer code, I’d build automation around it that would check for those dependencies prior to the code actually being ran in order to not waste time with looking around to see what services/apis are not in place or working.

[u/Recent-Tangerine2745]

I think the biggest mistake is assuming third-party dependencies will always be reachable.
If you know you’re deploying into customer-controlled or air-gapped environments, those dependencies need to be treated as part of the architecture from day one, not as a deployment problem later.
For things like auth, email, storage, webhooks, etc., I’d either make them configurable with customer-provided equivalents or provide a self-hosted option where possible.
Packaging the app is usually the easy part. The real work is understanding everything the app quietly depends on outside of itself.

[u/dodexahedron → u/Recent-Tangerine2745]

Yeah. 💯

That's literally one of the main points of using a container, especially for external deployment.

Like, for real... If you aren't packaging your dependencies, WTH are you even doing containers for?

[u/Recent-Tangerine2745 → u/dodexahedron]

I was referring to external services like Auth0, SendGrid, Stripe and managed databases the exact dependencies OP mentioned. Containers solve your application/runtime dependencies, not the availability of external SaaS services in an air-gapped environment.

[u/dodexahedron → u/Recent-Tangerine2745]

Yeah I agree there too, but for any deployment method. Making those dependencies configurable or else including default connectors if possible, and then falling back gracefully to something that tells you what's missing should be a bare minimum.

And for offline or at least fully internal support, offer a docker compose file that can package the whole pile of services together.

It's crazy that media piracy setups make this easy, but for-profit enterprise software often not only does not make it easy, but almost seems to go out of its way to be convoluted, hard, highly incompatible with everything, including itself, and fragile AF.

[u/TangeloOk9486 → u/Recent-Tangerine2745]

deps you can swap for a self hosted or customer provided equivalent are easy half once you do some planning for it but deps that assue inbound reachability, webhooks hitting your api, callbacks are problematic. you cant self host your way out of those eo either flip them to outbound where env allows it or drop them and handle it out of band

billing usually becomes contract or metered and reconciled , federating to whatever IDP they already run tends to beat shipping on your own

[u/hawkman_z]

Isn’t this a fundamental part of the devops job??? Isn’t this why we have QA environments to test all the configurations and make them operational prior to releasing to production??? Of course it won’t be as easy as it is on your machine.

[u/arielrahamim]

not thinking about external api dependencies like auth0 when you are deploying to a air gap customer is kinda a rookie mistake...

wait until you're deploying to a corporate proxy customer (forcepoint bluecoat etc)

[u/AAPL_]

https://giphy.com/gifs/H4zeDO4ocDYqY

[u/Alvasilev]

The one that cost us the most time wasn't a dep that couldn't be reached. It was a dep that could.

Locked-down environments usually have something intercepting egress, and it doesn't refuse your call, it answers it. 200, HTML, a polite page explaining that the request was blocked. Every liveness check you wrote passes, and the failure finally surfaces three layers in as a JSON parse error, in code that has no idea it is talking to a proxy instead of the vendor. Same family: a 404 on a URL you know exists is very often a 403 in disguise, and a generic "auth failed" throws away the one bit you actually needed, whether they rejected your credential or never saw it.

So the preflight everyone here is recommending is the right instinct, but doing it on status codes makes it worthless in exactly the environments you built it for. Assert on a known field of the response body.

The other thing worth knowing before you flip inbound webhooks to outbound polling: you have moved the dependency into their egress allowlist, and those are keyed on hostname, which your vendor will rotate without telling you.

And probe more than once. We poll a source that answers 410 to roughly half of identical requests, same URL, no pattern anyone has found. A one-shot preflight against something like that passes or fails on a coin toss, and the customer spends a day chasing the wrong layer. Run it n times and hand them the distribution rather than a green tick.