> For the complete documentation index, see [llms.txt](https://docs.stoobly.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoobly.com/core-concepts/scaffold/service.md).

# Service

A service can be a part of one or more workflows. When a workflow is run, only services that are a part of the workflow will be started.

## Properties

<details>

<summary>app-dir-path</summary>

Defaults to the current working directory. Configures where the scaffolded service files are created.

</details>

<details>

<summary>detached</summary>

Configures whether the `.stoobly` folder in the context directory path gets mounted. If the flag is set, a separate non-persistent Stoobly context gets created. The context directory path is specified when a workflow is run. To learn more see [here](/core-concepts/scaffold/workflow.md#core-workflows).

</details>

<details>

<summary>hostname</summary>

If a hostname for the service is specified, a proxy container will also be started when the service is instatiated as part of a workflow run.

</details>

<details>

<summary>priority</summary>

Configures the order which the service is run. Ranges from 0 to 10. If a service is configured with a priority of 0, then it will run before services with a greater priority value.

</details>

<details>

<summary>workflow</summary>

Configures which workflows the service belongs to, allowed values are `record` , `mock`, `test`. Defaults to no workflows.

</details>

## Containers

{% hint style="info" %}
To learn more about the purpose of each file, see [here](/core-concepts/scaffold/workflow.md#file-structure)
{% endhint %}

When service workflow is run, the following containers are started:

<figure><img src="/files/aMwrN7i5sqCNLJmavEHi" alt=""><figcaption><p>Service containers and files they depend on</p></figcaption></figure>

### init

The init container is the first container that gets run when a service starts. If it fails, dependent containers will not run. The first script that runs is the maintained `.init` script which then runs the customizable `init` script. Only the `.init`script will be overriten when the application is re-scaffolded.

### proxy

{% hint style="info" %}
This container only runs if a `hostname` property is configured
{% endhint %}

The proxy container is the last container that gets run. It provides a `lifecycle_hooks.py`script that enables customization of requests and response at different points of their lifecycles. To learn more:

{% content-ref url="/pages/ANLbxIN4T0Q4YF2llfer" %}
[Lifecycle Hooks](/core-concepts/agent/lifecycle-hooks.md)
{% endcontent-ref %}

For `mock` and `test` workflows, the following are also provided:

* `fixtures.yml` enables mapping URL's to static responses stored in files. To learn more:

{% content-ref url="/pages/GOo6YjREp8psDDjix3k1" %}
[Fixtures](/core-concepts/mock-api/fixtures.md)
{% endcontent-ref %}

* `public` folder enables defining mock request paths and responses using files stored in this folder. To learn more:

{% content-ref url="/pages/NUSptr4JMkNbMKFeZPwz" %}
[Public Folder](/core-concepts/mock-api/public-folder.md)
{% endcontent-ref %}

### custom

Custom containers can be defined in the provided `docker-compose.yml`.

{% hint style="info" %}
The `profiles`and `networks` properties need to be set accordingly
{% endhint %}

## Core Services

Core services are services maintained by Stoobly and maintains the following start order:

<figure><img src="/files/Gkiut71ZaEqlXS2JKQI4" alt=""><figcaption><p>Core services outlined in orange</p></figcaption></figure>

### build

Is the first service to be started and runs the [snapshot apply command](/guides/how-to-mock-apis/how-to-snapshot-requests/sharing-snapshots.md) to build mocks.

### gateway

Is responsible for routing requests from the host to the appropriate custom service.

### stoobly-ui

Provides a UI on <http://localhost:4200> to manage mocks and proxy configuration.

### entrypoint

Is the last service to be started and has the purpose of being extended in the provided `docker-compose.yml` with custom functionality.

## Get Started

{% content-ref url="/pages/BKCC6lKg9jOIW8EYkhK8" %}
[Scaffolding a Service](/guides/how-to-integrate-e2e-testing/how-to-scaffold-an-app/scaffolding-a-service.md)
{% endcontent-ref %}