Hey Sami!

There are a few ways you can approach this, depending on your goals/architecture.

Multiple Services for a Single Environment

If your services are all going to be deployed together into the same environment, you can specify a Dockerfile to use per service within the same repo, so you can structure it however you'd like that way.

Multiple Environments Defined in Your Git Repo

If you're doing multiple applications that you'd like deployed into separate environments, you can also specify a cycle.json file when you create your stack. Each application would be its own stack file, but each stack definition can be stored in the same monorepo. That way, you can have as many separate/independent applications as you'd like within the same repo.

Combining both options above gives you a pretty robust set of options to deploy using monorepos. In addition, you can deploy your stacks as a 'deployment' within an existing environment, so you get zero-downtime rainbow deployments, making it easy to rollback.

Hope that helps! Let me know if you have any other questions on using monorepos on Cycle.

I'd be remiss if I didn't also add that stacks and pipelines now also support variables, so while you're setting up your monorepo deployment process, you can take advantage of these to automatically tag versions of your application, clean up old builds in Cycle, and a lot more.