• Documentation
  • Pricing
© 2026 Serverless, Inc. All rights reserved.

Framework

  • Overview
  • Documentation
  • Plugins360
  • Pricing

Learn

  • Blog
  • GuidesUpdated
  • Examples240
  • Courses

Resources

  • Support
  • Security
  • Trust Center
  • Status

Community

  • Slack
  • GitHub47k
  • Forum
  • Meetups

Company

  • About
  • Careers
  • Contact
  • Partners

Legal

  • Terms of Service
  • Privacy Policy
  • Trademark
  • DMCA
Serverless Framework Logo

Serverless Framework

Intro
SetupUpgrading To V4ConceptsTutorialAWS CredentialsLicense Keys
DeployingPackagingBuildingTestingServicesFunctions
OverviewHTTP (API Gateway v2)REST (API Gateway v1)ActiveMQApplication Load BalancerAlexa SkillAlexa Smart HomeCloudWatch EventCloudWatch LogCloudFrontCognito User PoolEventBridge EventIoTIoT Fleet ProvisioningKafkaKinesis & DynamoDBMSKRabbitMQS3ScheduleSNSSQSWebsocket
LayersManaged InstancesAlertsVersion PruningDomainsIAM Function PermissionsParameters
OverviewSelf-reference serverless.ymlServerless CoreEnvironment VariablesCLI OptionsExternal YAML/JSON FilesJavascript propertiesGitDoppler
OverviewS3 ObjectsSSM Parameter Store & Secrets ManagerCloudFormation Stack Outputs
OverviewVaultTerraform State Output
ResourcesComposing ServicesDeployment BucketStatePython support
OverviewRuntimeGatewayMemoryBrowserCode InterpreterDev Mode
API Gateway Proxy
OverviewGeneral ConfigurationAuthenticationAPI KeysData SourcesResolversPipeline FunctionsCachingDelta SyncCustom DomainWAFCLI Commands
Deploying SAM/CFN TemplatesWorkflow Tips
OverviewCreating PluginsCLI OutputCustom CommandsCustom VariablesExtending the Configuration schemaExtending and overriding configuration
OverviewDashboardAxiom
Overviewdeploydeploy functiondeploy listdevdiffinfoinvokeinvoke localloginlogin awslogin aws ssologsmetricspackageplugin installplugin uninstallprintprunereconcileremoverollbackrollback functionsupportusage
Overview
OverviewMetricsTracesTroubleshoot
OverviewNode.jsPython
OutputsProviders
OverviewBranch DeploymentsPreview DeploymentsCustom ScriptsTestingPrivate PackagesNotificationsMono ReposDeploy in your own CI/CDBest PracticesTroubleshootingFAQ
OverviewSetupToolsAWS Integration
Serverless.yml Reference
Examples and TutorialsConfiguration Validation
  1. Dashboard
  2. CI CD
  3. Mono Repos

Mono-repo support using Trigger Directories

When first getting started with a Serverless Framework project it is common to have a single serverless.yml file in a single Github repo. As the project grows it is common to split up the single mono-service into micro-services in individual serverless.yml files by placing them into different directories in the same repo. In some cases, another directory may exist (e.g. /shared) which may contain shared libraries used by those services.

As an example, you may end up with a directory structure like this:

  • /service1
  • /service2
  • /shared

In this case, there is a /service1/serverless.yml and a /service2/serverless.yml. The services in those two directories may have a dependency on code defined in the /shared directory. We want to avoid redeploying ALL services every time any of the files change. Instead, we want to run tests and redeploy when the relevant changes are made, in particular:

  • If there is a change in /service1 only deploy /service1/serverless.yml.
  • If there is a change in /service2 only deploy /service2/serverless.yml.
  • If there is a change in /shared deploy both /service1/serverless.yml and /service2/serverless.yml.

In your Serverless CI/CD settings there is a section called “Trigger Directories”. This enables you to limit the changes in a git commit which trigger a deployment by identifying the directories containing the relevant changes. A deployment will occur only if changes in the specified directories are identified. If the changes are in a different directory, the service will not be deployed.

By default the option Always trigger a deployment is checked, which causes ALL changes in the repository to trigger a deployment, which means that all services will get redeployed. Instead we want to uncheck the option and only trigger deployments if changes are detected in the relevant directories.

Once unchecked, the base directory is added by default. This means that only changes in /service1 will cause /service1/serverless.yml to be deployed, and /service2 for /service2/serverless.yml respectively. Additionally we also want to deploy both services if changes in /shared are detected. As such, we’ll add ./shared as a trigger directory to both services.

With this configuration the changes in /service2 will not cause /service1 to be redeployed, and vice-versa and changes to /shared will result in both services getting deployed.

Edit this page
Prev NotificationsNextDeploy in your own CI/CD

Contents

  • Mono-repo support using Trigger Directories

Related

GuidesPluginsExamplesSlack CommunitySupport