Is there plans for Waypoint to expand into local development? Have the ability to do live updating and testing ala tilt.dev or garden.io? Would be great to have a tool that can handle the dev experience from local dev to prod.
Sounds like implementing https://shipyard.run/ as deploy and release stage, @nic 
1 Like
That’s a really excellent looking tool! That would abe great complement to the other half of the dev loop from what I mentioned. A smooth experience standup a local env would be a critical part of that.
Came here to ask this same question. Was really excited after seeing the announcement, and wanted to experiment this weekend.
What’s the recommended flow for developing multiple containerized services locally and then deploying?
Like, say if you have a Docker Compose setup. Would you continue using that for local dev, and just use Waypoint for the deployment and CI/CD bit?
And how does service-to-service networking and communication work? In Docker Compose and k8s, the internally routed URL is http://[service-name]:[port]. I read a bit about the URL service and the Waypoint entrypoint binary, but wasn’t sure if this was the same sort of thing.
I apologize if these are stupid questions. Would be fantastic to see a quick rundown of anyone’s workflow to go from local -> stage/prod if someone knows a good approach here.
We don’t currently plan on expanding Waypoint into dev. We want to make sure nail the deployment experience primarily and don’t want to distract ourselves from that. Dev is important so don’t misunderstand me by thinking I’m saying its not, but we have enough work to do on the deployment side. 
2 Likes
Definitely, completely understood there.
Was just curious (outside of Waypoint’s functionality itself) if there was a guide/example/recommended development pattern for going from multi-service local dev to deployment.
If this is outside of the scope of allowed discussions, no worries – just seemed like it might be a common question 
1 Like