Seed supports [monorepo Serverless applications](/content/docs/mono-repo-apps-in-seed/index.html). This means that you can have multiple Serverless Framework projects (services) in the same repo.

Once your app is created, you can add other services to it by hitting the **New Service** from your app pipeline.

Here you can point to the `serverless.yml` of the service you want to add.

Once Seed finds the file you can add the service. It will also auto-detect the name of the service from the `serverless.yml` file. You can change this later from the service settings.

If you don’t have a `serverless.yml` for the service yet, you can still add the service anyway. You’ll need to specify the **name of the service** manually. And make sure to add the file or change the path to it later.

The above assumes that you are trying to add a Serverless Framework service. If instead you are adding an [SST](https://github.com/sst/sst) service, make sure to select it from the **Service Type** dropdown.

Once you add the service, you’ll notice that it’s deployed across all the stages that you have configured for your app. This means that a commit to `master` (for example), would trigger a build in the **dev** stage for all the services in the app.

You can also trigger a build for a specific service in a stage by [manually triggering a deploy for it](/content/docs/updating-the-stage-source#manual-deploy/index.html).

### Newly created services

While working on a new service, you might want to add it to Seed in a specific stage first. For example, your dev stage might be tied to `master`, while you might have a feature branch called `new-service` that’s being deployed to a separate stage. Assume that the `new-service` branch has the new service that you’ve just added to the pipeline. This service cannot be deployed in dev because the service does not exist in the `master` branch.

For these cases, Seed uses the following scheme:

- If deploying a stage that doesn’t have the new service (dev in our example), the service is not deployed and it’s marked as **Skipped**.
- The skipped service does not affect the overall status of the build.
- However, if all services in a build are **Skipped**, the build is marked as **Failed**. This is because nothing was deployed in that build.

For further details on what can cause builds to be skipped, refer to our [chapter on skipped builds](/content/docs/skipped-builds/index.html).