---
sidebar_label: Multiple override layers
doc_id: 8f3c2c9c-4c1a-4c72-9e3e-2b81c7fdc4c0
description: >-
  Learn how to configure multiple override layers for agent-backed scopes, how
  layering works, precedence rules, and when to use this approach for advanced
  customizations such as Scheduled Tasks.
keywords:
  - scopes
  - overrides
  - multiple override layers
  - agent-backed scopes
  - scheduled tasks
  - customization
---

# Using multiple override layers

Agent-backed scopes support using **multiple override layers**, allowing you to extend or customize behavior by stacking
different override repositories. This gives you a flexible way to build on top of the base scope implementation
without duplicating code.


## How it works

You can specify multiple override repositories by passing more than one `--overrides-path` flag to the scope entrypoint.  
Each repository is loaded in order, creating a sequence of override layers.

```bash
/root/.np/nullplatform/scopes/entrypoint \
    --overrides-path=/root/.np/your-org/your-override-repo \
    --overrides-path=/root/.np/your-org/your-second-override-repo
```

:::info Good to know
Existing parameters, channels, and workflows do not require additional configuration.
:::

## How layers interact

Override layers behave like a "stack":

- Each override path can extend or replace behavior from earlier layers.
- Overrides may add files, modify them, or completely replace logic defined previously.
- This enables incremental customization without duplicating entire implementations.
 
## Priority rules

Override priority is **last-one-wins**:  
The **last** override provided in the command takes precedence over earlier ones.

This means that if multiple override repositories contain the **same file or logic**, the file from the *last* override path will overwrite the previous versions.

## Example setup

Below is a common configuration that combines the base Kubernetes scope, the Scheduled Task override, and a custom organization-level override:

```bash
/root/.np/nullplatform/scopes/entrypoint \
    --service-path=/root/.np/nullplatform/scopes/k8s \
    --overrides-path=/root/.np/nullplatform/scopes/scheduled_task \
    --overrides-path=/root/.np/acme-corp/platform-resources/custom-scope-override
```

#### Breakdown of layers

1. **Base Kubernetes scope**  
   Defines core lifecycle and deployment behavior.

2. **Scheduled Task override**  
   Adds logic specific to scheduled workloads.

3. **Custom organizational override**  
   Uses or adapts the Scheduled Task behavior with tenant-specific needs such as permissions, logging/APM configuration (e.g., Datadog), or specialized task logic.


## When to use multiple overrides

This approach is especially helpful when a scope needs multiple kinds of customization without merging everything into a single repository. 

A typical example is Scheduled Tasks, where you extend the base Kubernetes behavior, apply the task-specific override, and then apply any additional customizations your team or tenant requires.

The [Scheduled tasks scope](/docs/agent-backed-scopes/scheduled-tasks) page shows this pattern in detail.


## Best practices

- Use overrides thoughtfully: since the last override overwrites the rest, keep your paths ordered with intent.
- Keep responsibilities separate: aim for each override layer to have a clear purpose.
- Document your layers: helps teams reason about what is being overridden and why.