Notice how the heavy CPU and memory live entirely in the task container's **own** profile: the application container
stays small and responsive, while the reindex gets the resources it needs only for the seconds it runs.
## Step 1 - Define the task
Tasks are declared at the top level of `.upsun/config.yaml`, alongside `applications:` and `services:`. Let's define a
task that runs a heavy search reindex command against the same database the app uses.
```yaml title=".upsun/config.yaml" theme={null}
applications:
app:
type: php:8.5
relationships:
database: {}
# ...
services:
database:
type: postgresql:18
tasks:
reindex:
source:
root: /
type: php:8.5
run:
command: php bin/console app:reindex --no-interaction
timeout: 3600
relationships:
database: {}
mounts:
"/var/cache": { source: instance, source_path: var/cache }
```
A few things worth calling out:
* **`type`** uses the same runtime syntax as an application. Here the task reuses the app's PHP image so the
application command and its dependencies are available.
* **`run.command`** is the heavy job. It runs to completion, not as a daemon. If you need setup steps that require
service access, chain them at the start of the command, for example `php bin/console cache:warmup && php bin/console app:reindex`.
* **`run.timeout`** caps the run at one hour (the default). The maximum is `86400` (one day). On timeout, the platform
sends `SIGTERM`, then `SIGKILL` after a short grace period.
* **`relationships`** give the task its own connection to the database. Inside the task container, these appear in
`PLATFORM_RELATIONSHIPS` exactly as they do for an application.
* **`mounts`** declare writable directories. Remember that `instance` and `tmp` mounts are **reset between runs** — use
a `storage` or service mount if you need to persist data across runs.