[gregsadetsky]

and what did you use to manage git push deployments, setting env vars to replicate the heroku features?

also, you used replit for the frontend deployment? or frontend and some backend?

thanks - just super interesting as I'm in the space and feedback/real cases are really useful

[TuringNYC]

>> and what did you use to manage git push deployments, setting env vars to replicate the heroku features?

Yes Digital Ocean did all this, they were very feature-close to Heroku. We have over time migrated everything stable/prod to AWS just because AWS has more products and hence you have everything in one place inside a VPC (e.g. vector db)

For Replit, i'd use it for anything I can in early-stages. It helps to prototype ideas you are testing. You can iterate rapidly. For PROD we'd centralize onto AWS given the ecosystem.

[gregsadetsky]

cheers, I really appreciate your answers

and last q :-) re AWS - once you moved there, did you use something like elasticbean or app runner? or did you roll your own CI/CD/logging/scaling...?

[TuringNYC]

> and last q :-) re AWS - once you moved there, did you use something like elasticbean or app runner? or did you roll your own CI/CD/logging/scaling...?

We started with Lambdas because you can split work across people and keep dependencies to a minimum. Once your team gels and your product stabilizes, it is helpful to Dockerize it and go ECS, that is what we did. Some teams in the past used EKS but IMHO it required too much knowledge for the team to maintain, hence we've stuck with ECS.

All CI/CD via Github --> ECS. This is a very standard pipeline and works well locally for development also. ECS does the scaling quite well, and provides a natural path to EKS when you need the scale bigtime.

For logging, if I could choose I'd go Datadog but often you go with whatever the budget solution is.