Skip to content

Commit 19a0d79

Browse files
akyriakoakyriako
authored
Merge branch 'main' into 328-add-links-to-release-notes-in-portfolio-navigator
2 parents 7034b56 + c1f7b11 commit 19a0d79

File tree

46 files changed

+1776
-4
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

46 files changed

+1776
-4
lines changed

‎docs/blueprints/by-use-case/devops/dokploy/_category_.json‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
{
2+
"label": "Build a Self-Service App Hosting Platform with Dokploy",
3+
"link": {
4+
"type": "doc",
5+
"id": "dokploy"
6+
}
7+
}

‎docs/blueprints/by-use-case/devops/dokploy/configure-dokploy-for-otc.md‎

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
id: configure-dokploy-for-otc
3+
title: Configure Dokploy for Open Telekom Cloud
4+
tags: [dokploy, paas, swr, docker, swarm]
5+
sidebar_position: 2
6+
---
7+
8+
# Configure Dokploy for Open Telekom Cloud
9+
10+
This part of the blueprint explains how to configure Dokploy for use with Open Telekom Cloud. After deploying Dokploy, you need to integrate it with cloud services and external components to make the platform fully operational. The configuration steps covered in this guide include setting up container registries, defining S3-compatible storage destinations, assigning a server domain, updating the web server IP address, and connecting to a Git provider. Each of these steps ensures that Dokploy can interact seamlessly with Open Telekom Cloud resources and external systems, enabling you to build and manage applications efficiently.
11+
12+
:::warning attention
13+
All of the following steps must be configured for Dokploy to function correctly on Open Telekom Cloud.
14+
:::
15+
16+
## Configuring Registries
17+
18+
To use Dokploy effectively on Open Telekom Cloud, you must connect it to a container registry. In the registry is where application images will going to be stored, versioned, and retrieved during deployments. Dokploy needs this integration to push newly built images and to pull the correct versions when running applications. On Open Telekom Cloud, the Software Repository for Containers (SWR) is typically used, but external registries such as Docker Hub or GitHub Container Registry can also be configured, although SWR is highly recommended for tighter integration with the rest of the Open Telekom Cloud ecosystem and managed services. This step ensures that Dokploy can access images securely and deliver applications in a consistent and automated way.
19+
20+
The first step is to obtain a long-term SWR token, which you can generate by following the provided guide: [Obtaining a Long-Term Valid Docker Login Command](https://docs.otc.t-systems.com/software-repository-container/umn/image_management/obtaining_a_long-term_valid_docker_login_command.html).
21+
22+
Go to *Dokploy Console* -> *Settings* -> *Registries* and click *Add Registry* and fill in the values and click *OK*.
23+
24+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-25_13-23-29.png)
25+
26+
## Adding a Server Domain
27+
28+
Dokploy requires a server domain to provide a consistent and secure entry point for deployed applications. The domain should resolve to the public IP address of your Elastic Load Balancer. Once set, Dokploy uses this domain to assign subdomains to applications, route traffic through its reverse proxy, and manage TLS certificates for HTTPS access. This configuration ensures that applications are accessible under predictable URLs and can be secured with SSL termination.
29+
30+
Go to *Dokploy Console* -> *Settings* -> *Web Server*, set the *Domain* to `dokploy.example.com` and click *Save*.
31+
32+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-25_13-28-53.png)
33+
34+
:::warning
35+
**Do not** enable automatic SSL certificate provisioning in Dokploy when running on Open Telekom Cloud. TLS termination is already handled at the Elastic Load Balancer (ELB) level, which manages certificates and forwards plain HTTP traffic to Dokploy. Allowing Dokploy to request its own certificates would cause conflicts and may result in failed renewals, because Let’s Encrypt challenges cannot complete reliably behind the load balancer. Keeping certificate management centralized at the ELB ensures stable and predictable HTTPS access for all applications.
36+
:::
37+
38+
## Updating the Web Server's IP Address
39+
40+
The Server IP shown in Dokploy under *Web Server* reflects the node’s own outbound address, which in Open Telekom Cloud usually resolves to the NAT egress EIP. This value is detected locally and does not represent the actual entry point for external traffic. In production, applications are reached through the Elastic Load Balancer (ELB), which has its own public EIP. For correct operation, always configure your server domain to resolve to the ELB’s EIP, since this is the address exposed to clients and used for routing and TLS termination.
41+
42+
Go to *Dokploy Console* -> *Settings* -> *Web Server* -> *Web Server*, click *Server* -> *Update Server IP* and set `Server IP` to the EIP of the ELB and click *Update*.
43+
44+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-25_13-37-12.png)
45+
46+
## Connecting a Git Provider
47+
48+
Dokploy requires a connection to a Git provider to automate application delivery. By linking a repository, Dokploy can pull source code, build container images, and trigger deployments directly from commits. This integration keeps applications synchronized with the latest code changes and enables a consistent CI/CD workflow. Supported providers include GitHub, GitLab, Bitbucket and Gitea which can be connected through personal access tokens or service accounts.
49+
50+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-25_13-48-58.png)
51+
52+
Follow the instructions for your chosen provider, enter the required details, and then click *Configure*.
53+
54+
## Configuring S3 Destinations
55+
56+
To ensure persistent storage and reliable backups, Dokploy requires an S3-compatible destination. On Open Telekom Cloud, this is the Object Storage Service (OBS), which exposes an S3 API. By connecting Dokploy to an S3 destination, application data, logs, and backups can be stored outside of the container lifecycle, making them durable and recoverable across deployments. This configuration allows Dokploy to manage stateful workloads more reliably and ensures that important data is not lost when containers are restarted or replaced.
57+
58+
Go to *Dokploy Console* -> *Settings* -> *S3 Destinations* and click *Add Destination*. Configure it with the following settings and click *OK*:
59+
60+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-25_12-21-41.png)
61+
62+
## Setting up a Backup Schedule
63+
64+
Creating a backup schedule in Dokploy is essential to safeguard application databases and other persistent data. Containers and nodes can be restarted or replaced at any time, which makes local storage unreliable. By scheduling backups, Dokploy automatically exports data to an external S3-compatible service such as Open Telekom Cloud OBS, ensuring that recent restore points are always available. This protects against data loss during upgrades, configuration changes, or unexpected failures and provides a reliable way to recover critical information.
65+
66+
:::warning
67+
Dokploy backups **work only when PostgreSQL runs as a container managed by the platform**, since Dokploy can execute dump operations directly inside the container. Because in this blueprint we use Open Telekom Cloud RDS, **backups must be handled through the RDS service itself**, because Dokploy cannot access the managed database process. In this case, make sure to configure a backup schedule in RDS to ensure data protection and recovery options remain in place.
68+
69+
For detailed instructions, see [Configuring an Automated Backup Policy](https://docs.otc.t-systems.com/relational-database-service/umn/working_with_rds_for_postgresql/backups_and_restorations/configuring_an_automated_backup_policy.html#rds-09-0027).
70+
:::

‎docs/blueprints/by-use-case/devops/dokploy/deploy-applications-with-dokploy.md‎

Lines changed: 212 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,212 @@
1+
---
2+
id: deploy-applications-with-dokploy
3+
title: Deploy Applications with Dokploy
4+
tags: [devops, ci, cd, cicd, dokploy, paas, ecs, docker, swarm, gitops]
5+
sidebar_position: 3
6+
---
7+
8+
# Deploy Applications with Dokploy
9+
10+
The final part of this blueprint describes how to deploy highly available user workloads with Dokploy on Open Telekom Cloud, positioning it as an open-source alternative to platforms such as Vercel, Netlify, Azure App Services and AWS Elastic Beanstalk.
11+
12+
Before we deploy any application with Dokploy we first need to create a Project. Go to *Dokploy Console* -> *Home* -> *Projects* and click *Create Project*, give it a name and click *Create*.
13+
14+
## Deploying a Docker Stack
15+
16+
### Simple Application
17+
18+
Open the created project and click *Create Service* -> *Docker Compose*. Fill in the **Name**, in this case `whoami` as we are going to install the `traefik/whoami` application, a Go server that prints OS information and HTTP request to output. Choose `Stack` as **Compose Type** and click *Create*:
19+
20+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_08-56-01.png)
21+
22+
Go to *General* and disable *Auto-deploy*, click *Raw*, paste the following YAML in the text area and click *Save*:
23+
24+
```yaml
25+
version: "3.8"
26+
services:
27+
whoami:
28+
image: containous/whoami:v1.5.0
29+
deploy:
30+
replicas: 1
31+
```
32+
33+
Go to *Domains* and click *Add Domain*. Select the service, in this case there is only one, namely `whoami`, from the **Service Name** drop-box and set **Container Port** to `80` (that should always be the port that container is listening to and not a custom one that you would like to expose the service to).
34+
35+
:::important
36+
Keep **HTTPS** disabled because TLS is terminated at the Elastic Load Balancer.
37+
:::
38+
39+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_09-19-51.png)
40+
41+
Next, define the **Host** URL. You can choose between a testing address or one intended for production workloads. Clicking the *dice button* on the right, generates a random URL from the traefik.me service and sets it as your **Host**. This is suitable for testing, as it does not support SSL certificates.
42+
43+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_09-26-14.png)
44+
45+
:::note
46+
[Traefik.me](https://traefik.me/) is a wildcard DNS service, similar to nip.io or xip.io, that resolves any IP address.
47+
:::
48+
49+
For production, you can use `whoami.dokploy.example.com`, assuming that `dokploy.example.com` was configured as the Web Server Domain Address in the earlier steps.
50+
51+
Finally, click *Create*, go back to *General*, and select *Deploy*. If the configuration is correct, your workload will be deployed on the worker nodes of the swarm and both endpoints should now be accessible:
52+
53+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_09-41-40.png)
54+
55+
:::note
56+
Applications under your domain are secure because TLS is terminated at the ELB with a wildcard certificate that covers `*.dokploy.example.com`. When a user visits any app like `whoami.dokploy.example.com`, the certificate’s SAN matches the hostname, the chain validates, and the browser marks the session as secure.
57+
:::
58+
59+
### Multi-Service Application
60+
61+
The previous example was simplified. Next, we will demonstrate how to deploy a Docker stack with multiple interdependent services that require more advanced configuration. Open the created project and click *Create Service* -> *Docker Compose*. Fill in the **Name**, in this case `typesense`, choose `Stack` as **Compose Type** and click *Create*. In this example we are going to deploy the following services:
62+
63+
- A single-node [Typesense](https://typesense.org/) server.
64+
- A [Typesense Dashboard](https://github.com/bfritscher/typesense-dashboard) to manage and browse collections.
65+
- A [Typesense DocSearch Scraper](https://github.com/typesense/typesense-docsearch-scraper), customized to index data in Typesense from an external [Docusaurus](https://docusaurus.io/) site.
66+
- A [Docker Job Scheduler](https://github.com/mcuadros/ofelia) that will trigger the scraper every 5 minutes.
67+
68+
Go to *General* and disable *Auto-deploy*, click *Raw*, paste the following YAML in the text area and click *Save*:
69+
70+
```yaml
71+
version: '3.8'
72+
73+
services:
74+
typesense:
75+
image: typesense/typesense:30.0.rc10
76+
networks:
77+
- dokploy-network
78+
volumes:
79+
- typesense-data:/data
80+
environment:
81+
TYPESENSE_API_KEY: ${TYPESENSE_API_KEY}
82+
TYPESENSE_DATA_DIR: /data
83+
TYPESENSE_ENABLE_CORS: "true"
84+
85+
dashboard:
86+
image: bfritscher/typesense-dashboard
87+
networks:
88+
- dokploy-network
89+
environment:
90+
VITE_AUTH_ENABLED: "false"
91+
92+
docsearch-scraper:
93+
image: typesense/docsearch-scraper:0.12.0.rc13
94+
networks:
95+
- dokploy-network
96+
deploy:
97+
replicas: 1
98+
placement:
99+
constraints:
100+
- node.role == worker
101+
depends_on:
102+
- typesense
103+
environment:
104+
CONFIG: |
105+
{
106+
"index_name": "${SCRAPER_COLLECTION_INDEX}",
107+
"start_urls": [
108+
"https://${SCRAPER_TARGET_HOST}/"
109+
],
110+
"sitemap_urls": [
111+
"https://${SCRAPER_TARGET_HOST}/sitemap.xml"
112+
],
113+
"sitemap_alternate_links": true,
114+
"stop_urls": [
115+
"/tests"
116+
],
117+
"selectors": {
118+
"lvl0": {
119+
"selector": "(//ul[contains(@class,'menu__list')]//a[contains(@class, 'menu__link menu__link--sublist menu__link--active')]/text() | //nav[contains(@class, 'navbar')]//a[contains(@class, 'navbar__link--active')]/text())[last()]",
120+
"type": "xpath",
121+
"global": true,
122+
"default_value": "Documentation"
123+
},
124+
"lvl1": "header h1",
125+
"lvl2": "article h2",
126+
"lvl3": "article h3",
127+
"lvl4": "article h4",
128+
"lvl5": "article h5, article td:first-child",
129+
"lvl6": "article h6",
130+
"text": "article p, article li, article td:last-child"
131+
},
132+
"strip_chars": " .,;:#",
133+
"custom_settings": {
134+
"separatorsToIndex": "_",
135+
"attributesForFaceting": [
136+
"language",
137+
"version",
138+
"type",
139+
"docusaurus_tag"
140+
],
141+
"attributesToRetrieve": [
142+
"hierarchy",
143+
"content",
144+
"anchor",
145+
"url",
146+
"url_without_anchor"
147+
]
148+
},
149+
"conversation_id": [
150+
"833762294"
151+
],
152+
"nb_hits": 46250
153+
}
154+
TYPESENSE_API_KEY: ${TYPESENSE_API_KEY}
155+
TYPESENSE_HOST: typesense
156+
TYPESENSE_PORT: 8108
157+
TYPESENSE_PROTOCOL: http
158+
SCRAPER_TARGET_HOST: ${SCRAPER_TARGET_HOST}
159+
SCRAPER_COLLECTION_INDEX: ${SCRAPER_COLLECTION_INDEX}
160+
REQUEST_FINGERPRINTER_IMPLEMENTATION: "2.7"
161+
command: python3 /app/src/docsearch.py
162+
restart: no
163+
164+
scheduler:
165+
image: mcuadros/ofelia:latest
166+
networks:
167+
- dokploy-network
168+
depends_on:
169+
- docsearch-scraper
170+
command: daemon --docker
171+
volumes:
172+
- /var/run/docker.sock:/var/run/docker.sock:ro
173+
labels:
174+
ofelia.job-run.docsearch-scraper.schedule: "@every 5m"
175+
ofelia.job-run.docsearch-scraper.container: "docsearch-scraper"
176+
restart: unless-stopped
177+
178+
volumes:
179+
typesense-data:
180+
```
181+
182+
:::note
183+
Notice that we have introduced two new configuration properties in the YAML file:
184+
185+
- `networks`: All containers are placed in the same Docker network, allowing them to communicate with each other internally without interruption.
186+
- `deploy.placement.constrains`: We explicitly specify the node group where containers are deployed. This ensures that manager nodes are not overloaded with user workloads and allows future separation of workloads by introducing specialized worker pools, such as GPU or ARM-based nodes.
187+
188+
:::
189+
190+
Next thing you need to do is set the environment variables required on project, environment or service level. For more details on how Dokploy is handling enviroment variables see [Environment Variables](https://docs.dokploy.com/docs/core/variables) in the official Dokploy documentation.
191+
192+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_12-18-32.png)
193+
194+
Then, go to *Domains* and create 2 domains. One for the **typesense** service (set **Container Port** to 8108), and one for the **typesense-dashboard** service ((set **Container Port** to 8108).
195+
196+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_11-11-43.png)
197+
198+
If the configuration is correct, all containers should be deployed on the worker nodes of the swarm and we could now visit the dashboard endpoint and observe our search engine collections and indices getting populated:
199+
200+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_12-09-05.png)
201+
202+
## Deploying from a Dokploy Template
203+
204+
The Dokploy template library provides a collection of preconfigured application stacks that can be deployed with minimal setup. Templates cover common services such as databases, monitoring tools, and developer utilities, offering sensible defaults that reduce configuration effort and errors. They can be used directly for quick deployments or extended with custom settings for production environments. Teams may also add their own templates to the library to standardize and simplify application delivery across projects.
205+
206+
![img](/img/docs/blueprints/by-use-case/devops/dokploy/Screenshot_from_2025-09-26_13-57-42.png)
207+
208+
:::warning
209+
Most templates in the Dokploy library are designed for single-server setups. When running on Docker Swarm, you **may** need to adjust them to ensure they work reliably in a clustered environment.
210+
:::
211+
212+
<!-- ## Building and Deploying from a Git Repo -->

0 commit comments

Comments
 (0)