> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/3.0/shared-capabilities/services/custom-service-agent.md).
# Custom Service Agent
Use the **Custom Service Agent** when the target you want to test is not coming from the Kubernetes discovery inventory. You define the service yourself under **Project Settings → Discovery**, then bind it to a Resilience Testing infrastructure so experiments and probes can run against it.
This path is separate from the bulk [Automated service onboarding](/resilience-testing/shared-capabilities/services/service-discovery.md) wizard. Kubernetes discovery invents workloads from the cluster. Custom Service Agent invents the service record from the metadata you enter.
{% hint style="info" %}
**FEATURE FLAG**
Service onboarding is currently behind a feature flag (`CHAOS_RISK_SERVICES_ENABLED`). Contact your Harness sales representative to get it enabled for your account.
{% endhint %}
***
### Before you begin
* **A Resilience Testing infrastructure:** Custom services require an explicit infrastructure assignment when you onboard them. Create the infrastructure first. Go to [Infrastructure](/resilience-testing/3.0/chaos-testing/infrastructure.md) to set one up.
* **A connector that reaches the target:** Use a connector that can reach the VM, cloud account, or endpoint you are describing.
* **Kubernetes discovery path when applicable:** If the target is a workload already visible to a discovery agent, use [Automated service onboarding](/resilience-testing/shared-capabilities/services/service-discovery.md) for multiple workloads or [Manual service onboarding](/resilience-testing/shared-capabilities/services/manual-service-onboarding.md) for one workload instead of recreating it by hand.
***
### Where Custom Service Agent lives
1. Go to **Resilience Testing → Project Settings → Discovery** (Project Discovery).
2. Open the **Custom Discovery Agent** (also labeled **Custom Service Agent** in the detail view).
3. The list shows every custom service in the project, with **Name**, **Type**, and who last updated it.
From here you can search, filter by **Type**, and select **+ New Custom Service**.
***
### Supported custom service types
When you select **+ New Custom Service**, the library groups the types you can create:
| Category | Types |
| -------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Kubernetes** | Service, Workload, Node |
| **AWS** | Classic Load Balancer, Network Load Balancer, Application Load Balancer, EC2 Instance, Lambda, Relational Database Service |
| **Linux** | Linux VM, Linux VM Process |
| **Windows** | Windows VM, Windows VM Process |
| **Other** | Other |
Pick the type that matches the target. The wizard steps that follow depend on that type. The rest of this page uses **Linux VM** as the worked example. Other types follow the same Overview → configuration pattern with fields appropriate to that resource.
***
### Create a Linux VM custom service
1. On **Custom Service Agent**, select **+ New Custom Service**.
2. In the library, select **Linux VM**.
#### Overview
Enter the service metadata.
| Field | Description |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Display name for the service. |
| **Id** | Service ID generated from the name. Edit it before you create the service if you need a stable identifier for automation. After creation, treat it as immutable. |
| **Description** | Optional. |
| **Tags** | Optional labels for filtering. |
Select **Next**.
#### Endpoint configuration
Describe how Harness reaches the VM. Add one or more of:
* **FQDN**
* **IP Address**
* **Socket Path**
Select **+ Add** for each value you need, then select **Next**.
#### Service configuration
Enter the VM details Harness stores on the service:
| Field | Example |
| ------------------- | ----------------------------- |
| **Hostname** | `my-linux-server.example.com` |
| **OS Distribution** | `Ubuntu`, `CentOS`, `RHEL` |
| **OS Version** | `20.04`, `8.4` |
| **Kernel** | `5.4.0-74-generic` |
Select **Create** to finish.
Assign the service to a Resilience Testing infrastructure when the flow asks for it. Custom services do not inherit infrastructure from a discovery agent the way Kubernetes discovered workloads do.
***
### After you create a custom service
* The service appears in **Insights → Services** with its type (for example `Linux VM`).
* Attach probes and target the service from Chaos Studio the same way you do for discovered services. Go to [Services](/resilience-testing/3.0/shared-capabilities/services.md#use-a-service-to-fill-in-probe-inputs-in-chaos-studio) for probe input fill-in.
* Run risk scans and experiments against it once the infrastructure binding is in place.
***
### Custom Service Agent compared with Kubernetes discovery
| | Kubernetes discovery onboarding | Custom Service Agent |
| --------------------------- | -------------------------------------------------- | ---------------------------------------------------------------- |
| **How targets appear** | Discovery agent invents workloads from the cluster | You invent the service from metadata you enter |
| **Typical use** | Greenfield or brownfield cluster onboarding | Linux or Windows VMs, AWS resources, other non-inventory targets |
| **Infrastructure** | Bound through the infrastructure you onboard | Must assign infrastructure explicitly |
| **Default probes** | Attached in bulk discovery onboarding | Attach probes yourself after creation |
| **Risk scanning in wizard** | Part of the three-stage onboarding flow | Run a risk scan after the service exists |
***
### Next steps
* [Automated service onboarding](/resilience-testing/shared-capabilities/services/service-discovery.md): Discover, scan, and onboard Kubernetes workloads in bulk.
* [Manual service onboarding](/resilience-testing/shared-capabilities/services/manual-service-onboarding.md): Add one workload from the discovery inventory.
* [Services](/resilience-testing/3.0/shared-capabilities/services.md): Manage services after they exist.
* [Infrastructure](/resilience-testing/3.0/chaos-testing/infrastructure.md): Create the infrastructure custom services must bind to.
* [Chaos experiments](/resilience-testing/3.0/chaos-testing/experiments.md): Target a custom service with a fault.