mirror of
https://github.com/Dokploy/website
synced 2025-06-26 18:16:01 +00:00
feat: migration to fumadocs 14
This commit is contained in:
173
apps/docs-v2/content/docs/core/applications/advanced.mdx
Normal file
173
apps/docs-v2/content/docs/core/applications/advanced.mdx
Normal file
@@ -0,0 +1,173 @@
|
||||
---
|
||||
title: Advanced
|
||||
description: Learn how to use advanced features in your application.
|
||||
---
|
||||
|
||||
This section is designed for experienced users who need to manage complex configurations and orchestration settings in Dokploy. Here, you can execute custom commands, manage cluster replicas, select Docker registries, and configure Docker Swarm settings.
|
||||
|
||||
### Run Command
|
||||
|
||||
- **Purpose**: Allows users to execute custom shell commands directly within the container.
|
||||
- **Usage**: Enter the command you need to run in the provided field and click 'Save' to execute it within the container environment. This tool is particularly useful for debugging or specific administrative tasks.
|
||||
|
||||
### Cluster Settings
|
||||
|
||||
- **Purpose**: Manages the scaling and distribution of the application across multiple servers or nodes.
|
||||
- **Replicas**: Set the number of instances of your application that should be running.
|
||||
- **Registry Selection**: Choose the Docker registry from which your container images will be pulled. This is crucial for ensuring that the correct images are used during deployment.
|
||||
|
||||
#### Important Note
|
||||
Always click 'Redeploy' after modifying the cluster settings to apply the changes.
|
||||
|
||||
### Swarm Settings
|
||||
|
||||
Swarm settings allow for detailed configuration of how containers are orchestrated within the Docker Swarm.
|
||||
|
||||
#### Health Check
|
||||
|
||||
- **Purpose**: Ensures that containers are running smoothly and restarts them if they fail.
|
||||
- **Configuration**: Specify parameters like test commands, intervals, timeouts, start periods, and retries.
|
||||
|
||||
#### Restart Policy
|
||||
|
||||
Defines how containers should be handled if they exit or fail, the configuration is as follows:
|
||||
|
||||
- **Condition**: Specifies under what condition a restart should occur.
|
||||
- **Delay**: Sets the time delay between restarts.
|
||||
- **Max Attempts**: Limits the number of restart attempts.
|
||||
- **Window**: Defines the time window used to evaluate the restart policy.
|
||||
|
||||
#### Update Config
|
||||
|
||||
Manages the deployment and update process of services in the swarm, the configuration is as follows:
|
||||
|
||||
|
||||
- **Parallelism**: Number of containers to update simultaneously.
|
||||
- **Delay**: Time between updates.
|
||||
- **Failure Action**: Action to take if an update fails.
|
||||
- **Monitor**: Duration to monitor a container after an update.
|
||||
- **Max Failure Ratio**: The fraction of containers that are allowed to fail before the update is considered a failure.
|
||||
- **Order**: The order in which containers are stopped and started during an update.
|
||||
|
||||
#### Placement
|
||||
|
||||
Controls where containers are placed within the swarm based on specific rules and preferences, the configuration is as follows:
|
||||
|
||||
- **Constraints**: Conditions that must be met for a container to be placed on a node.
|
||||
- **Preferences**: Preferences for placing containers across nodes to spread load evenly.
|
||||
|
||||
### Rollback Config
|
||||
|
||||
Manages the rollback process for services when updates fail, the configuration is as follows:
|
||||
|
||||
- **Parallelism**: Number of containers to rollback simultaneously.
|
||||
- **Delay**: Time between rollbacks.
|
||||
- **FailureAction**: Action to take if a rollback fails.
|
||||
- **Monitor**: Duration to monitor a container after a rollback.
|
||||
- **MaxFailureRatio**: The fraction of containers that are allowed to fail before the rollback is considered a failure.
|
||||
- **Order**: The order in which containers are stopped and restarted during a rollback.
|
||||
|
||||
### Mode
|
||||
|
||||
Defines how services are replicated within the swarm, the configuration is as follows:
|
||||
|
||||
- **Replicated**: Services are replicated across nodes as specified.
|
||||
- **Replicas**: Number of replicas per service.
|
||||
- **Global**: A single instance of the service runs on every node.
|
||||
- **ReplicatedJob**: Runs a job in a replicated manner.
|
||||
- **MaxConcurrent**: Maximum number of jobs running concurrently.
|
||||
- **TotalCompletions**: Total number of times the jobs need to complete.
|
||||
|
||||
### Network
|
||||
|
||||
Configures network settings for the services, the configuration is as follows:
|
||||
|
||||
- **Target**: Specifies the network name.
|
||||
- **Aliases**: Provides aliases for the network.
|
||||
- **DriverOpts**: Network driver options like MTU size and host binding.
|
||||
|
||||
### Labels
|
||||
|
||||
Assigns metadata to containers to help identify and organize them, the configuration is as follows:
|
||||
|
||||
- **Labels**: Key-value pairs assigned to the service. For example:
|
||||
1. `com.example.app.name`: "my-app"
|
||||
2. `com.example.app.version`: "1.0.0"
|
||||
|
||||
|
||||
### Note
|
||||
Modifying Swarm Settings requires careful consideration as incorrect configurations can disrupt the entire container orchestration. Always ensure you understand the implications of the changes you are making.
|
||||
|
||||
|
||||
## Resources
|
||||
|
||||
Manage the memory and CPU resources allocated to your applications or databases.
|
||||
|
||||
- **Memory Reservation**: The minimum amount of memory guaranteed to the application.
|
||||
- **Memory Limit**: The maximum amount of memory the application can use.
|
||||
- **CPU Limit**: The maximum number of CPU units that the application can utilize.
|
||||
- **CPU Reservation**: The minimum number of CPU units reserved for the application.
|
||||
|
||||
|
||||
### Volumes/Mounts
|
||||
|
||||
Configure persistent storage for your application to ensure data remains intact across container restarts and deployments.
|
||||
|
||||
|
||||
**Bind Mount**: Maps a host file or directory to a container file or directory. Typically used for specific configurations or databases.
|
||||
1. **Host Path**: Path on the host.
|
||||
2. **Mount Path**: Path in the container.
|
||||
|
||||
**Volume Mount**: Uses Docker-managed volumes that are easier to back up and migrate than bind mounts.
|
||||
1. **Volume Name**: Name of the Docker-managed volume.
|
||||
2. **Mount Path**: Path in the container where the volume is mounted.
|
||||
|
||||
**File Mount**: Specifically for single files, useful for configuration files.
|
||||
1. **Content**: The content to store in the file.
|
||||
2. **Mount Path**: Path in the container where the file is placed.
|
||||
|
||||
File mounts are a dokploy features, this create a file in a folder called `files` inside your project, so it recreates every single time you deploy your project.
|
||||
|
||||
<ImageZoom src="/assets/file-mount-configuration.webp" width={800} height={630} className="rounded-lg"/>
|
||||
|
||||
<ImageZoom src="/assets/file-mount.png" width={800} height={630} className="rounded-lg"/>
|
||||
|
||||
### Redirects
|
||||
|
||||
Redirect requests to your application to another URL based on specified rules, enhancing navigational efficiency and SEO.
|
||||
|
||||
- **Regex**: Enter a regular expression to match the URLs that need redirecting.
|
||||
- **Replacement**: Specify the target URL where traffic should be redirected.
|
||||
- **Permanent**: Toggle this option to apply a permanent (HTTP 301) redirection, indicating to browsers and search engines that the page has moved permanently.
|
||||
|
||||
#### Example
|
||||
To redirect all traffic from "http://localhost" to "http://mydomain", set the Regex as `http://localhost/(.*)` and the Replacement as `http://mydomain/$1`.
|
||||
|
||||
|
||||
### Security
|
||||
|
||||
Add basic authentication to your application to restrict access.
|
||||
|
||||
- **Username**: Enter a username.
|
||||
- **Password**: Enter a password.
|
||||
|
||||
#### Important Note
|
||||
Adding basic authentication will prompt users for a username and password before allowing access to the application. Use this for environments where an additional layer of security is required.
|
||||
|
||||
|
||||
### Ports
|
||||
|
||||
Expose your application to the internet by configuring network ports, allowing external access.
|
||||
|
||||
- **Published Port**: The port number on the host that will route traffic to your application.
|
||||
- **Target Port**: The port number inside the container that the application uses.
|
||||
- **Protocol**: Choose between TCP and UDP based on your application's requirements.
|
||||
|
||||
#### Important Note
|
||||
Ensure that the published port does not conflict with other services on the host to avoid port binding errors, also this port is used mostly for accesing the application from the outside, eg your-ip:port, this is not for accessing the application trought a domain.
|
||||
|
||||
### Traefik
|
||||
|
||||
Provides a dynamic and robust method to manage HTTP traffic to your services, including load balancing and SSL termination.
|
||||
|
||||
- **Rules**: Define complex routing, load balancing, and security configurations using Traefik's powerful rule-based configuration system.
|
||||
86
apps/docs-v2/content/docs/core/applications/auto-deploy.mdx
Normal file
86
apps/docs-v2/content/docs/core/applications/auto-deploy.mdx
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: Auto Deploy
|
||||
description: "Learn how to automatically deploy your application to Dokploy."
|
||||
---
|
||||
|
||||
Automatically deploying your application to Dokploy can be achieved through two primary methods: using Webhooks or the Dokploy API. Each method supports various platforms and provides a streamlined deployment process.
|
||||
|
||||
## Github
|
||||
|
||||
For Github, we provide autodeploy without any configuration. This will automatically deploy your application whenever you push to your repository.
|
||||
|
||||
## Webhook URL
|
||||
|
||||
Webhooks allow you to automatically deploy your application whenever changes are made in your source repository.
|
||||
|
||||
- GitHub
|
||||
- GitLab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- DockerHub
|
||||
|
||||
### Configuration Steps
|
||||
|
||||
1. **Enable Auto Deploy**: Toggle the 'Auto Deploy' button found in the general tab of your application settings in Dokploy.
|
||||
2. **Obtain Webhook URL**: Locate the Webhook URL from the deployment logs.
|
||||
|
||||
<ImageZoom
|
||||
src="/assets/webhook-url.png"
|
||||
alt="Webhook URL"
|
||||
width={1000}
|
||||
height={500}
|
||||
/>
|
||||
|
||||
3. **Configure Your Repository**:
|
||||
- Navigate to your repository settings on your chosen platform.
|
||||
- Add the webhook URL provided by Dokploy.
|
||||
- Ensure the settings match the configuration necessary for triggering the webhook.
|
||||
|
||||
<ImageZoom
|
||||
src="/assets/webhook-github.png"
|
||||
alt="Webhook URL"
|
||||
width={1000}
|
||||
height={500}
|
||||
/>
|
||||
|
||||
#### Important Notes
|
||||
|
||||
- **Branch Matching**: When using Git-based providers (GitHub, GitLab, etc.), ensure that the branch configured in Dokploy matches the branch you intend to push to. Misalignment will result in a "Branch Not Match" error.
|
||||
- **Docker Tags**: For deployments using DockerHub, ensure the tag pushed matches the one specified in Dokploy.
|
||||
- The steps are the same for all the providers.
|
||||
|
||||
### API Method
|
||||
|
||||
Deploy your application programmatically using the Dokploy API from anywhere.
|
||||
|
||||
### Steps to Deploy Using API
|
||||
|
||||
Steps:
|
||||
|
||||
1. **Generate a Token**: Create an API token in your profile settings on Dokploy.
|
||||
2. **Retrieve Application ID**:
|
||||
|
||||
```http
|
||||
curl -X 'GET' \
|
||||
'https://your-domain/api/project.all' \
|
||||
-H 'accept: application/json'
|
||||
-H 'Authorization: Bearer <token>'
|
||||
```
|
||||
|
||||
This command lists all projects and services. Identify the applicationId for the application you wish to deploy.
|
||||
|
||||
3. **Trigger Deployment**:
|
||||
|
||||
```http
|
||||
curl -X 'POST' \
|
||||
'https://your-domain/api/application.deploy' \
|
||||
-H 'accept: application/json' \
|
||||
-H 'Content-Type: application/json' \
|
||||
-H 'Authorization: Bearer <token>' \
|
||||
-d '{
|
||||
"applicationId": "string"
|
||||
}'
|
||||
```
|
||||
|
||||
This API method allows for flexible, scriptable deployment options, suitable for automated systems or situations where direct repository integration is not feasible.
|
||||
In this way you can deploy your application from anywhere, you can use the webhook URL or the API.
|
||||
34
apps/docs-v2/content/docs/core/applications/build-type.mdx
Normal file
34
apps/docs-v2/content/docs/core/applications/build-type.mdx
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Build Type
|
||||
description: "Learn about the different build types available in Dokploy, including Nixpacks, Dockerfile, and Buildpack options."
|
||||
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
|
||||
|
||||
Dokploy offers three distinct build types for deploying applications, each suited to different development needs and preferences.
|
||||
|
||||
### Nixpacks
|
||||
|
||||
This is the default build type in Dokploy. When you select Nixpacks, Dokploy builds your application as a Nixpack, which is optimized for ease of use and efficiency.
|
||||
|
||||
You can read more about Nixpacks [here](https://nixpacks.com/).
|
||||
|
||||
### Dockerfile
|
||||
|
||||
If your project includes a Dockerfile, you can specify its path. Dokploy will use this Dockerfile to build your application directly, giving you full control over the build environment and dependencies.
|
||||
|
||||
### Buildpack
|
||||
|
||||
Dokploy supports two types of buildpacks:
|
||||
|
||||
- **Heroku**: Adapted from Heroku's popular cloud platform, these buildpacks are designed for compatibility and ease of migration.
|
||||
- **Paketo**: Provides cloud-native buildpacks that leverage modern standards and practices for building applications.
|
||||
|
||||
<Callout>
|
||||
**Tip:** We recommend using the `Nixpacks` build type as it is the most
|
||||
straightforward and commonly used option for most applications.
|
||||
</Callout>
|
||||
|
||||
By choosing the appropriate build type, you can tailor the deployment process to best fit your application's requirements and your operational preferences.
|
||||
48
apps/docs-v2/content/docs/core/applications/domains.mdx
Normal file
48
apps/docs-v2/content/docs/core/applications/domains.mdx
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Domains
|
||||
description: Domains
|
||||
---
|
||||
|
||||
This section outlines how to configure domains for your applications in Dokploy, ensuring that your applications are accessible via custom URLs.
|
||||
|
||||
|
||||
### Add Domain
|
||||
|
||||
Associate custom domains with your application to make it accessible over the internet.
|
||||
|
||||
- **Host**: The domain name that you want to link to your application (e.g., `api.dokploy.com`).
|
||||
- **Path**: The specific path within the domain where the application should be accessible.
|
||||
- **Container Port**: The port on the container that the domain should route to.
|
||||
- **Certificate**: Select whether to secure the domain with SSL/TLS certificates. Dokploy supports automatic provisioning of SSL certificates via Let's Encrypt.
|
||||
- **HTTPS**: Toggle this on to enable HTTPS for your domain, providing secure, encrypted connections.
|
||||
|
||||
#### Steps to Add a Domain
|
||||
1. Click 'Add Domain'.
|
||||
2. Fill in the domain details, including host, path, and port.
|
||||
3. Choose to enable HTTPS and select a certificate option.
|
||||
4. Click 'Create' to apply the settings.
|
||||
|
||||
### Generate Domain
|
||||
|
||||
Quickly set up a domain for development or testing purposes without needing to register a domain.
|
||||
|
||||
- **Generate TraefikMe Domain**: Creates a free domain provided by TraefikMe. This is ideal for testing or temporary access before a proper domain is purchased.
|
||||
|
||||
#### Steps to Generate a Domain
|
||||
1. Click 'Generate Domain'.
|
||||
2. Choose 'Generate TraefikMe Domain' for a quick setup.
|
||||
3. A domain will be automatically assigned to your application.
|
||||
|
||||
### Managing Domains
|
||||
|
||||
- **View and Modify**: Existing domains are listed with options to edit settings or remove them.
|
||||
- **Details**: Each domain entry shows the configured host, path, port, and whether HTTPS is enabled.
|
||||
|
||||
### Note
|
||||
|
||||
Proper domain configuration is crucial for the accessibility and security of your application. Always verify domain settings and ensure that DNS configurations are properly set up to point to the correct IP addresses. Enable HTTPS to enhance security and trust, especially for production environments.
|
||||
|
||||
|
||||
### Important Clarification on Container Ports
|
||||
|
||||
The "Container Port" specified in the domain settings is exclusively for routing traffic to the correct application container through Traefik, and does not expose the port directly to the internet. This is fundamentally different from the port settings in the "Advanced -> Ports" section, which are used to directly expose application ports. The container port in the domain settings ensures that Traefik can internally direct traffic to the specified port within the container based on the domain configuration.
|
||||
58
apps/docs-v2/content/docs/core/applications/index.mdx
Normal file
58
apps/docs-v2/content/docs/core/applications/index.mdx
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Applications
|
||||
description: "Explore the multiple deployment methods available in Dokploy, including GitHub, Git, Docker, and automated deployments via webhooks."
|
||||
---
|
||||
|
||||
Applications in Dokploy are treated as a single service, entity or container, making it easy and intuitive for users to work with each application in its own workspace.
|
||||
|
||||
We offer multiple functionalities that you can use to manage your applications, such as:
|
||||
|
||||
## General
|
||||
|
||||
Configure the source of your code, the way your application is built, and also manage actions like deploying, updating, and deleting your application, and stopping it.
|
||||
|
||||
## Environment
|
||||
|
||||
If you need to assign environment variables to your application, you can do so here.
|
||||
|
||||
In case you need to use a multiline variable, you can wrap it in double quotes just like this `'"here_is_my_private_key"'`.
|
||||
|
||||
## Monitoring
|
||||
|
||||
Four graphs will be displayed for the use of memory, CPU, disk, and network. Note that the information is only updated if you are viewing the current page, otherwise it will not be updated.
|
||||
|
||||
## Logs
|
||||
|
||||
If you want to see any important logs from your application that is running, you can do so here and determine if your application is displaying any errors or not.
|
||||
|
||||
## Deployments
|
||||
|
||||
You can view the last 10 deployments of your application. When you deploy your application in real time, a new deployment record will be created and it will gradually show you how your application is being built.
|
||||
|
||||
We also offer a button to cancel deployments that are in queue. Note that those in progress cannot be canceled.
|
||||
|
||||
We provide a webhook so that you can trigger your own deployments by pushing to your GitHub, Gitea, GitLab, Bitbucket, DockerHub repository.
|
||||
|
||||
## Domains
|
||||
|
||||
This is where you will assign your domain so that your application can be accessed from the internet.
|
||||
|
||||
There are two ways to assign a domain:
|
||||
|
||||
1. Create a custom domain.
|
||||
2. Use a generated domain, we use traefik.me to generate free domains.
|
||||
|
||||
## Advanced Settings
|
||||
|
||||
This section provides advanced configuration options for experienced users. It includes tools for custom commands within the container, managing Docker Swarm settings, and adjusting cluster settings such as replicas and registry selection. These tools are typically not required for standard application deployment and are intended for complex management and troubleshooting tasks.
|
||||
|
||||
- **Run Command**: Execute custom commands directly in the container, after the application has been build & running.
|
||||
- **Cluster Settings**: Configure the number of replicas and select the Docker registry for your deployment to manage how your application scales and where it pulls images from.
|
||||
- **Swarm Settings**: Access additional Docker Swarm configurations for detailed orchestration and scaling across multiple nodes.
|
||||
- **Resources**: Adjust the CPU and memory allocation for your application.
|
||||
- **Volumes**: To ensure data persistence across deployments, configure storage volumes for your application, you can create Volumes, Binds, File Mounts.
|
||||
- **Ports**: Expose your application to the internet by configuring network ports.
|
||||
- **Traefik**: Modify Traefik settings to manage HTTP request handling for your application.
|
||||
|
||||
### Note
|
||||
Adjust these settings carefully as incorrect configurations can significantly impact your application’s functionality and availability.
|
||||
58
apps/docs-v2/content/docs/core/applications/providers.mdx
Normal file
58
apps/docs-v2/content/docs/core/applications/providers.mdx
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Providers
|
||||
description: Learn how to use providers in your application.
|
||||
---
|
||||
|
||||
Dokploy offers several deployment methods, streamlining the process whether you're utilizing GitHub, any Git provider, Docker, or automated deployments.
|
||||
|
||||
- GitHub
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Git (Any Git Provider)
|
||||
- Docker
|
||||
- Drop(Drag and Drop .zip)
|
||||
|
||||
## GitHub, Gitlab, Bitbucket
|
||||
|
||||
Go to [Git Sources](/docs/core/git-sources/github) and select the provider you want to use.
|
||||
|
||||
## Git
|
||||
|
||||
For deployments from any Git repository, whether public or private, you can use either SSH or HTTPS:
|
||||
|
||||
### Public Repositories (HTTPS)
|
||||
|
||||
1. Enter the repository URL in `HTTPS URL`.
|
||||
2. Type the branch name.
|
||||
3. Click on `Save`.
|
||||
|
||||
### Private Repositories
|
||||
|
||||
For private repositories, is required to first create an SSH Key.
|
||||
|
||||
1. Go to [SSH Keys](/docs/core/ssh-keys/overview) and click on `Create SSH Key`.
|
||||
2. Click on `Generate RSA SSH Key` and copy the `Public Key`.
|
||||
|
||||
<ImageZoom
|
||||
src="/assets/dokploy-ssh-key.png"
|
||||
width={800}
|
||||
height={630}
|
||||
className="rounded-lg"
|
||||
/>
|
||||
|
||||
You can then copy the SSH key and paste it into the settings of your account.
|
||||
|
||||
<ImageZoom
|
||||
src="/assets/private-repository.png"
|
||||
width={800}
|
||||
height={630}
|
||||
className="rounded-lg"
|
||||
/>
|
||||
|
||||
This enables you to pull repositories from your private repository, a method consistent across nearly all providers.
|
||||
|
||||
## Docker
|
||||
|
||||
For Docker deployments:
|
||||
|
||||
- Provide a Docker image. For private repositories, enter the username and password.
|
||||
Reference in New Issue
Block a user