Dokploy/templates
1
0
Fork 0
mirror of https://github.com/Dokploy/templates.git synced 2026-07-17 03:45:30 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: add per-template setup instructions (supabase, trigger.dev)

Browse Source 
Adds instructions.md files for the Supabase and Trigger.dev templates and
renders them in the template browser as a new Instructions tab in the
template dialog (fetched from blueprints/<id>/instructions.md, rendered
with a small dependency-free markdown component).

Also removes the placeholder blueprints/ackee/instructions.md so it does
not surface as an empty Instructions tab.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Mauricio Siu
2026-07-14 12:04:30 -06:00
parent 17efd705a4
commit 03a60bb417
6 changed files with 349 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
blueprints/ackee/instructions.md
View File

@@ -1,4 +0,0 @@
## Instructions
We don't have nothing to show here....

61
blueprints/supabase/instructions.md Normal file
View File

@@ -0,0 +1,61 @@
# Supabase Setup Instructions
## Deploy
1. In Dokploy, create the service from the **Supabase** template (requires Dokploy `>= 0.22.5`).
2. Dokploy automatically generates all secrets for you (`POSTGRES_PASSWORD`, `JWT_SECRET`, `ANON_KEY`, `SERVICE_ROLE_KEY`, `DASHBOARD_PASSWORD`, etc.). You can review them in the **Environment** tab of the service.
3. Deploy and wait for all containers to become healthy. The first deploy can take several minutes while the Postgres database initializes.
## Log in to Supabase Studio
The main domain of the template points to the `kong` API gateway (port `8000`), which protects Supabase Studio with basic authentication:
- **Username**: the value of `DASHBOARD_USERNAME` (default: `supabase`)
- **Password**: the value of `DASHBOARD_PASSWORD`
Both values are in the **Environment** tab of the service in Dokploy.
## API URL and keys
To connect an application (for example with `supabase-js`):
- **API URL**: `https://<your-domain>` (requests are routed through Kong)
- **anon key**: the value of `ANON_KEY` in the Environment tab
- **service_role key**: the value of `SERVICE_ROLE_KEY` in the Environment tab (server-side only, never expose it to browsers)
## Recommended configuration
Review these variables in the **Environment** tab before using Supabase in production:
- `SUPABASE_PUBLIC_URL` and `API_EXTERNAL_URL`: must point to your Supabase domain with the correct `http`/`https` scheme (the template sets them from your domain automatically).
- `SITE_URL` and `ADDITIONAL_REDIRECT_URLS`: must point to the application that uses Supabase for authentication.
- `SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASS`, `SMTP_ADMIN_EMAIL`, `SMTP_SENDER_NAME`: required for auth emails (sign-up confirmations, password resets). The template ships with placeholder values, so no real emails are sent until you configure a real SMTP provider.
## Warning: changing POSTGRES_PASSWORD after the first deploy
The Postgres data directory (mounted at `files/volumes/db/data`) is initialized **once**, on the first deploy, using the value of `POSTGRES_PASSWORD` at that moment. The same password is also assigned to the internal Supabase roles (`authenticator`, `pgbouncer`, `supabase_auth_admin`, `supabase_functions_admin`, `supabase_storage_admin`) by an init script that only runs on first boot.
If you later change `POSTGRES_PASSWORD` in the Environment tab and redeploy, the password stored **inside the database does not change**. The other services will start using the new password while the database still expects the old one, and you will see errors such as `invalid_password` or `password authentication failed`.
To actually change the password, use one of these options:
### Option A: change it inside the database (keeps your data)
1. Open a terminal into the `db` container (in Dokploy: your Supabase service, `db` container, **Terminal**) and run `psql -U postgres`.
2. Execute the following, using your new password:
```sql
ALTER USER postgres WITH PASSWORD 'your-new-password';
ALTER USER supabase_admin WITH PASSWORD 'your-new-password';
ALTER USER authenticator WITH PASSWORD 'your-new-password';
ALTER USER pgbouncer WITH PASSWORD 'your-new-password';
ALTER USER supabase_auth_admin WITH PASSWORD 'your-new-password';
ALTER USER supabase_functions_admin WITH PASSWORD 'your-new-password';
ALTER USER supabase_storage_admin WITH PASSWORD 'your-new-password';
```
3. Update `POSTGRES_PASSWORD` in the Environment tab to the same value and redeploy.
### Option B: reinitialize the database (deletes ALL data)
Only if the instance has no data you care about: stop the service, delete the `files/volumes/db/data` directory of the service, set the new `POSTGRES_PASSWORD`, and deploy again. The database will be initialized from scratch with the new password.

54
blueprints/triggerdotdev/instructions.md Normal file
View File

@@ -0,0 +1,54 @@
# Trigger.dev Setup Instructions
## Deploy
1. In Dokploy, create the service from the **Trigger.dev** template.
2. Dokploy generates all required secrets (`MAGIC_LINK_SECRET`, `SESSION_SECRET`, `ENCRYPTION_KEY`, database credentials, etc.) automatically.
3. Deploy and wait until the containers are running. The main domain points to the `webapp` service (port `3000`).
If you serve the app over HTTPS, set `TRIGGER_PROTOCOL=https` in the **Environment** tab (the template defaults to `http`) so that login links use the correct scheme, then redeploy.
## First login (no email server configured)
Trigger.dev logs you in with **magic links** sent by email. The template does not configure an email transport by default, so the email is never actually sent. Instead, **the magic link is printed to the logs of the `webapp` container**:
1. Open `https://<your-domain>` and enter your email address to request a magic link.
2. In Dokploy, go to your Trigger.dev service, open the **Logs** tab, and select the `webapp` container/service.
3. Look for a recent log entry containing a URL like `.../magic?token=...` (search for `magic`).
4. Copy that URL into your browser to complete the login.
## Configure email sending (optional)
To have magic links delivered by email, add these variables in the **Environment** tab and redeploy.
Using SMTP:
```
EMAIL_TRANSPORT=smtp
FROM_EMAIL=trigger@example.com
REPLY_TO_EMAIL=trigger@example.com
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_SECURE=false
SMTP_USER=your-smtp-user
SMTP_PASSWORD=your-smtp-password
```
Using [Resend](https://resend.com):
```
EMAIL_TRANSPORT=resend
FROM_EMAIL=trigger@example.com
REPLY_TO_EMAIL=trigger@example.com
RESEND_API_KEY=your-resend-api-key
```
## Restrict who can sign up (recommended)
By default anyone who can reach the webapp can request a magic link. Restrict access with a regex of allowed email addresses:
```
WHITELISTED_EMAILS=you@example\.com|teammate@example\.com
```
You can also grant admin rights by email with `ADMIN_EMAILS` (same regex format).