---
title: Architecture Overview
url: https://www.tines.com/docs/self-hosted/deploying-tines/docker-compose/architecture-overview/
updated: 2026-03-18T08:59:22+00:00
---

*[tines.com](https://www.tines.com/llms.txt) › [Docs](https://www.tines.com/llms.txt) › [Self-Hosted](https://www.tines.com/llm/docs/self-hosted.md) › [Deploying Tines](https://www.tines.com/llm/docs/self-hosted/deploying-tines.md) › [Docker Compose](https://www.tines.com/llm/docs/self-hosted/deploying-tines/docker-compose.md)*

# Architecture Overview

*[View on tines.com](https://www.tines.com/docs/self-hosted/deploying-tines/docker-compose/architecture-overview/)*

## Architecture overview

![](https://www.datocms-assets.com/55802/1718634832-generic-tines-diagram-docker-compose-numbered.png)

## Basic architecture

Tines is a Rails application that uses a PostgreSQL database for its persistent data storage and Redis for its cached data storage and message queuing.

It features two core application containers: `tines-app` and `tines-sidekiq`. `tines-app` runs the Rails server for web application hosting/receiving webhooks. `tines-sidekiq` runs background worker processes. Both containers read and write to and from the PostgreSQL database and Redis cache - they don't communicate directly, instead, they swap data and messages through PostgreSQL/Redis.

Both the `tines-app` and `tines-sidekiq` containers use the same `tines-app` Docker image with different entry points (`start-tines-app` and `start-tines-sidekiq` respectively).

The `tines-app` and `tines-sidekiq` containers both make requests to external services to run your automation stories.

The `tines-sidekiq` container may be optionally configured to periodically load new Action templates from Tines (at [integrations.tines.com](http://integrations.tines.com/)) and to send basic version and feature usage information back to Tines (at hq.tines.io).

A `tines-nginx` container is usually deployed in front of the `tines-app` container to terminate SSL. Alternatively, any load balancer, load balancer service, or reverse proxy can fill this role.

## Serving the web application

A user's browser connects via HTTPS to the Tines web application via the `tines-nginx` container or an LB/reverse proxy, which terminates the SSL connection and connects to the `tines-app` container over HTTP.

## Running Actions on `tines-sidekiq`

The Tines product features 7 different types of automation "Actions", 3 of which cause Tines to connect to external services: IMAP, Email (SMTP), HTTP Request.

When a user "runs" an Action via the web application, a task is enqueued in the Redis cluster by the `tines-app` container. The `tines-sidekiq` container reads from this queue, reads related data from the PostgresSQL database and performs the Action, which may result in a HTTP, SMTP or IMAP request to an external server.

The data gathered from these requests is stored in an "event" in the PostgresSQL database.

Actions can also run as a result of an upstream Action running successfully, or on a schedule. When this happens, a task is enqueued in the Redis cluster by the `tines-sidekiq` container for each Action that will run.

## Testing Actions on `tines-app`

When "test" mode is invoked via the web application, the tines-app container directly executes the Action (rather than enqueuing it via the Redis instance for later execution by the `tines-sidekiq` container).

When this happens, the tines-app container may itself make a HTTP, SMTP or IMAP request to an external server.

## Receiving webhooks

An external service may post webhooks to the `tines-app` container through the same `tines-nginx` container or LB/reverse proxy used to host the web application.

When a webhook is received, the data is stored in an event in the PostgresSQL database. Further downstream Actions may be executed in turn by the `tines-app` container enqueuing tasks in the Redis cluster.