> For the complete documentation index, see [llms.txt](https://docs.spreo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spreo.io/technical/technical-overview.md).

# Technical Overview

This page gives a brief overview of the Spreo architecture and system requirements.

### Introduction

Spreo is a dynamic, real-time application providing users with a rich interactive environment to work collaboratively. It is primarily deployed into a virtual private cloud operated by Deqo Software Ltd and provided in the form of Software as a Service.

This article describes the architecture of Spreo. See our [Security](https://spreo.io/security) and [Privacy Policy](https://spreo.io/privacy) pages for more information on our security and data protection practices.

### Logical Topology

Spreo is exposed to customers as a [single page web application](https://en.wikipedia.org/wiki/Single-page_application). Behind this, there are a number of services working in synergy to provide a working service. From a logical perspective (ignoring hardware), these are:

<table><thead><tr><th>Service</th><th width="354">Product / Provider</th><th width="150">Role</th></tr></thead><tbody><tr><td>Web Gateway</td><td>Caddy</td><td>Acts as reverse proxy and load balancer.</td></tr><tr><td>Content Delivery Network</td><td>BunnyCDN</td><td>Provides edge cache for static assets &#x26; SPA build files.</td></tr><tr><td>App Server</td><td>NodeJS Application</td><td>Application API (HTTP based) and Auth/Login UI.</td></tr><tr><td>Podopolis</td><td>Elixir Application</td><td>Socket server that enables the real time collaboration functionality.</td></tr><tr><td>Main Database</td><td>Postgres</td><td>Stores all system data except for board contents.</td></tr><tr><td>Object Database</td><td>MongoDB</td><td>Stores board contents.</td></tr><tr><td>Cache</td><td>Redis</td><td>Provides a cache and short term storage solution.</td></tr><tr><td>Message Queue</td><td>NSQ</td><td>Enables inter-service communication between components.</td></tr><tr><td>File Store</td><td>S3 Compatible Storage</td><td>Stores static assets &#x26; user uploaded data.</td></tr><tr><td>App Worker</td><td>NodeJS Application</td><td>Background job processor for various system tasks/functionality.</td></tr><tr><td>Snapper</td><td>NodeJS Application</td><td>Generates board preview images and PDF exports via Puppeteer.</td></tr></tbody></table>

The diagram below shows the logical topology layout including the data transfer routes. Blue lines are one way transfers, purple lines are bi-directional transfers.

![](https://content.gitbook.com/content/wEhLPSRTDuhd61395hZu/blobs/hs7cWwUKlCE7wMPmNU7E/image.png)

### Physical Topology

#### Cloud Deployment

Within the main cloud deployment, we utilize Digital Ocean with the following:

* Ubuntu VMs for App Server, App Worker, Snapper, Podopolis, NSQ, Redis & Caddy
* Digital Ocean Managed Postgres & MongoDB instances
* Digital Ocean Spaces (S3 Compatible Storage)
* Bunny CDN as the external CDN provider

Each component runs directly on a dedicated VM of a size applicable for the current system load.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.spreo.io/technical/technical-overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.