# 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stoobly.com/core-concepts/scaffold/service.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.