Deployment Overview
What remoteEaze needs in production, which deployment paths are available, and how to move from prerequisites to a working system.
Last updated
remoteEaze runs as a small application stack rather than a single binary. A complete deployment needs:
- a PostgreSQL database
- a Redis instance
- S3-compatible object storage
- the API service
- the background worker
- the web application
- a migration step before the API and worker begin normal traffic
Production baseline
Use this as the recommended baseline for a production app host:
| Resource | Recommendation |
|---|---|
| CPU | 8 vCPU |
| Memory | 32 GB RAM |
| Storage | 200+ GB NVMe SSD |
Separate heavy auxiliary services from the app host
Self-hosted SigNoz and self-hosted object storage such as SeaweedFS should run on different machines where possible. They compete with the app stack for CPU, memory, and disk I/O.
Deployment methods
All deployment methods below are supported and documented as first-class paths.
| Method | Best fit | Creates Postgres/Redis for you | Build requirement |
|---|---|---|---|
| Dokploy + Traefik | Managed Docker host with Dokploy | Yes | Pulls prebuilt runtime images |
| Docker Compose + source build | Self-managed host building from source | Yes | Builds local images from this repository |
| Docker Compose + registry images | Self-managed host pulling prebuilt images | Yes | Pulls prebuilt runtime images |
| PM2 / manual runtime | Operators managing processes and reverse proxy directly | No | You build and run each service yourself |
How the pieces fit together
The normal runtime topology is:
migrateruns database migrations.apistarts and serves:- business APIs under
/api/v1/* - auth under
/api/auth/* - health endpoints
- Swagger docs
- Redis dashboard
- Bull Board
- business APIs under
workerstarts queue processing and scheduled jobs.webserves the SPA.
Recommended public routing shape
The cleanest operator-facing layout is:
| Public URL | Target |
|---|---|
https://remote-eaze.example.com/ | Web app |
https://remote-eaze.example.com/api/* | API |
https://remote-eaze.example.com/admin/redis | API |
https://remote-eaze.example.com/admin/queues | API |
https://api.remote-eaze.example.com/health | API |
https://api.remote-eaze.example.com/health/live | API |
https://api.remote-eaze.example.com/documentation | API |
This keeps normal browser traffic on the root domain while preserving a clean API hostname for direct health and docs access.
Compose files in this repository
The repository includes four deployment-oriented compose files at the repo root:
| File | Purpose |
|---|---|
docker-compose.dokploy.yml | Dokploy-oriented app deployment using prebuilt images and Infisical |
docker-compose.registry.yml | Direct Docker Compose deployment using prebuilt images |
docker-compose.source.yml | Direct Docker Compose deployment building from the local checkout |
docker-compose.docs.yml | Standalone compose file for the documentation site |
Deployment flow
Use this order regardless of deployment method:
- Review Prerequisites.
- Fill in the required values from Environment Reference.
- Configure Storage Setup.
- Configure Email and Notifications.
- Choose your deployment path:
- Apply Routing and Domains.
- Run the required Post-Deploy Bootstrap.
- Connect telemetry and monitoring using Telemetry and Monitoring.
- Use Troubleshooting if anything fails.
What is optional and what is not
The following are optional by deployment style:
- Infisical
- GHCR image pulls
- self-hosted docs deployment
- PM2/manual runtime
- extra native/mobile origins
- telemetry backend choice
The following are not optional for a working app:
- PostgreSQL
- Redis
- S3-compatible storage
- valid application secrets
- database migrations
- at least one system administrator bootstrap
Next step
Continue with Prerequisites.