I confirm this works!

Cloudron sets up Dawarich with 512 MB minimum, but this seems to be incorrect: https://dawarich.app/docs/hardware-requirements/

My app also crashed lacking memory, and it went up to 1.33 GB for me when I set it up. I suggest to correct the Cloudron package here to make sure it'll run stable.

Thank you, I didn't know! I have now set it up using Owntracks and it seems to work.

Shouldn't this app package offer "leave user management to the app"? I can only choose whether to allow all users from this cloudron instance or limit it to certain users and groups, but the actual app allows account creation by non-cloudron accounts.

I have just looked into this and wanted to point out that there's no Android app, only iOS. In case anyone was wondering.

Okay, find below information about how the app runs. What I haven't tested:

• Setting up notification e-mails (should be simple using SMTP)
• Actually transferring the data (a test account could be set up)
• Handling the integrated update mechanism: so far, all updates would need to be done manually.

The Core Concept

Standard deployment (Bluesky PDS original):

• Docker Compose file with 3 separate containers:
  • pds - The main application
  • caddy - Reverse proxy and TLS termination
  • watchtower - Automatic container updates

Cloudron deployment:

• Only 1 container - The main application (pds)
• Cloudron provides everything else:
  • Reverse proxy (TLS, HTTPS)
  • Health monitoring
  • Storage management
  • Update mechanism

Remove from the application:

• Caddy service - Cloudron's reverse proxy handles HTTPS/TLS
• Watchtower service - Cloudron's update system handles updates
• Docker Compose file - Cloudron doesn't use compose; it builds from Dockerfile

Keep from the application:

• The main app (Node.js + PDS in this case)
• The Dockerfile (but modify it to use a startup script)
• All application code and logic

Files You Need to Create

Three new files are required:

1. startup.sh - Environment validation and initialization

2. CloudronManifest.json - Cloudron deployment configuration

3. Modifications to Dockerfile - Add startup script and health check

#!/bin/bash
set -e

# Startup script for Bluesky PDS on Cloudron
# This script validates required environment variables and initializes the application

# Required environment variables
REQUIRED_VARS=(
  "PDS_HOSTNAME"
  "PDS_JWT_SECRET"
  "PDS_ADMIN_PASSWORD"
  "PDS_PLC_ROTATION_KEY_K256_PRIVATE_KEY_HEX"
)

# Check required variables
echo "Validating environment variables..."
for var in "${REQUIRED_VARS[@]}"; do
  if [[ -z "${!var:-}" ]]; then
    echo "ERROR: Required environment variable $var is not set"
    exit 1
  fi
done

# Set default data directory if not specified
PDS_DATA_DIRECTORY="${PDS_DATA_DIRECTORY:-/app/data}"
PDS_BLOBSTORE_DISK_LOCATION="${PDS_BLOBSTORE_DISK_LOCATION:-$PDS_DATA_DIRECTORY/blocks}"
PDS_BLOB_UPLOAD_LIMIT="${PDS_BLOB_UPLOAD_LIMIT:-104857600}"

# Set default service URLs (point to public AT Protocol network)
PDS_DID_PLC_URL="${PDS_DID_PLC_URL:-https://plc.directory}"
PDS_BSKY_APP_VIEW_URL="${PDS_BSKY_APP_VIEW_URL:-https://api.bsky.app}"
PDS_BSKY_APP_VIEW_DID="${PDS_BSKY_APP_VIEW_DID:-did:web:api.bsky.app}"
PDS_REPORT_SERVICE_URL="${PDS_REPORT_SERVICE_URL:-https://mod.bsky.app}"
PDS_REPORT_SERVICE_DID="${PDS_REPORT_SERVICE_DID:-did:plc:ar7c4by46qjdydhdevvrndac}"
PDS_CRAWLERS="${PDS_CRAWLERS:-https://bsky.network}"

# Set defaults for optional variables
LOG_ENABLED="${LOG_ENABLED:-true}"
PDS_PORT="${PDS_PORT:-3000}"
NODE_ENV="${NODE_ENV:-production}"

# Create required directories
echo "Initializing data directories..."
mkdir -p "$PDS_DATA_DIRECTORY"
mkdir -p "$PDS_BLOBSTORE_DISK_LOCATION"

# Export all PDS variables for the application
export PDS_HOSTNAME
export PDS_JWT_SECRET
export PDS_ADMIN_PASSWORD
export PDS_PLC_ROTATION_KEY_K256_PRIVATE_KEY_HEX
export PDS_DATA_DIRECTORY
export PDS_BLOBSTORE_DISK_LOCATION
export PDS_BLOB_UPLOAD_LIMIT
export PDS_DID_PLC_URL
export PDS_BSKY_APP_VIEW_URL
export PDS_BSKY_APP_VIEW_DID
export PDS_REPORT_SERVICE_URL
export PDS_REPORT_SERVICE_DID
export PDS_CRAWLERS
export LOG_ENABLED
export PDS_PORT
export NODE_ENV

# Optional environment variables (only export if set)
if [[ -n "${PDS_EMAIL_SMTP_URL:-}" ]]; then
  export PDS_EMAIL_SMTP_URL
fi
if [[ -n "${PDS_EMAIL_FROM_ADDRESS:-}" ]]; then
  export PDS_EMAIL_FROM_ADDRESS
fi
if [[ -n "${PDS_PRIVACY_POLICY_URL:-}" ]]; then
  export PDS_PRIVACY_POLICY_URL
fi
if [[ -n "${LOG_DESTINATION:-}" ]]; then
  export LOG_DESTINATION
fi
if [[ -n "${LOG_LEVEL:-}" ]]; then
  export LOG_LEVEL
fi

echo "Starting Bluesky PDS on Cloudron"
echo "  Hostname: $PDS_HOSTNAME"
echo "  Data directory: $PDS_DATA_DIRECTORY"
echo "  Blob storage: $PDS_BLOBSTORE_DISK_LOCATION"
echo "  Port: $PDS_PORT"

# Start the application
exec node --enable-source-maps index.js

FROM node:20.19-alpine3.22 as build

RUN corepack enable

# Build goat binary
ENV CGO_ENABLED=0
ENV GODEBUG="netdns=go"
WORKDIR /tmp
RUN apk add --no-cache git go
RUN git clone https://github.com/bluesky-social/goat.git && cd goat && git checkout v0.1.2 && go build -o /tmp/goat-build .

# Move files into the image and install
WORKDIR /app
COPY ./service ./
RUN corepack prepare --activate
RUN pnpm install --production --frozen-lockfile > /dev/null

# Uses assets from build stage to reduce build size
FROM node:20.19-alpine3.22

RUN apk add --update dumb-init bash

# Avoid zombie processes, handle signal forwarding
ENTRYPOINT ["dumb-init", "--"]

WORKDIR /app
COPY --from=build /app /app
COPY --from=build /tmp/goat-build /usr/local/bin/goat
COPY startup.sh /app/startup.sh

RUN chmod +x /app/startup.sh

EXPOSE 3000
ENV PDS_PORT=3000
ENV NODE_ENV=production
# potential perf issues w/ io_uring on this version of node
ENV UV_USE_IO_URING=0

# Health check to verify PDS is running and responsive
HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 \
  CMD node -e "require('http').get('http://localhost:3000/xrpc/_health', (r) => {if (r.statusCode !== 200) throw new Error(r.statusCode)})" || exit 1

CMD ["/app/startup.sh"]

LABEL org.opencontainers.image.source=https://github.com/bluesky-social/pds
LABEL org.opencontainers.image.description="AT Protocol PDS"
LABEL org.opencontainers.image.licenses=MIT

{
  "id": "io.cloudron.bluesky-pds",
  "version": "1.0.0",
  "manifestVersion": 2,
  "title": "Bluesky PDS",
  "description": "A Personal Data Server for AT Protocol and Bluesky",
  "tagline": "Self-hosted Bluesky server",
  "author": "Bluesky Social",
  "website": "https://github.com/bluesky-social/pds",
  "documentationUrl": "https://github.com/bluesky-social/pds",
  "tags": ["chat", "sync"],

  "httpPort": 3000,
  "healthCheckPath": "/xrpc/_health",

  "addons": {
    "localstorage": {
      "volumePath": "/app/data"
    },
    "sendmail": {}
  }
}

Make sure to change all hardcoded references for the data directory /pds to /app/data!

Then make sure to set all the required env variables. The admin password is for the server app, not your bluesky account.

As I said, this gets the app to run and report positively to the healthcheck, now does someone want to test this?

P.S.: I have now created and deleted a user via curl, and verified that it persists a server restart.

This is impressive. I think an MCP server should be part of the core Cloudron software some time soon!

I am not familiar with the Cloudron API, can I use this to get the logs of an individual app, or only its status?

This should actually be doable:

1. All of the main app is in one container
2. The database container can be replaced with the postgres addon
3. Migrations need to be handled in the Dockerfile manually

@sfeldkamp It works, I could set the app up. But I didn't migrate my data, because apparently, you can't go back to cloud later, and I wasn't sure if I wanted to maintain this at the moment.

I can share a tutorial, but you came first, and I don't want to spoil the fun for you, so feel free to try first

It has happened again and I was able to catch a few issues that might be related:

1. WebRTC: ICE failed, add a STUN server and see about:webrtc for more details
2. Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://translate.googleapis.com/element/log?format=json&hasfast=true&authuser=0. (Reason: CORS request did not succeed). Status code: (null).
3. Consumer Transport failed
   Object { id: "9d932828-8aba-4b93-af58-235cb3a06c1b" }

/home/yellowtent/platformdata/logs/box.log - doesn't contain anything related to mirotalk

Network logs: lists that umami is failing (probably blocked by plugin) and googletranslate (see above)

I am sending about:webrtc via e-mail, because it is a huge fail and contains personal information.

It's in System → Settings, just saying ...

The original is linked above, the changes are explained (and quite minimal).

Are you using Firefox? Did you know you can self-host the sync server on Cloudron? (you know ... because you can). I have just tested this, and it works between Firefox on Ubuntu and Android.

Here is a tutorial for anyone interested:

Replication Guide: Adapting Syncstorage-RS for Cloudron

This guide explains how to take the original mozilla-services/syncstorage-rs repository and adapt it for a single-container deployment on Cloudron with PostgreSQL.

1. Create the Manifest (CloudronManifest.json)

Cloudron requires a manifest file to understand the application requirements. Create this file in the root of the repository.

CloudronManifest.json:

{
  "manifestVersion": 2,
  "title": "Syncstorage-RS",
  "author": "Mozilla Services",
  "description": "Firefox Sync storage server built with Rust",
  "version": "0.21.1",
  "httpPort": 8000,
  "addons": {
    "postgresql": {
      "version": "14.9"
    }
  },
  "healthCheckPath": "/__heartbeat__"
}

---

2. Create the Start Script (cloudron-entrypoint.sh)

Cloudron provides database credentials through environment variables (CLOUDRON_POSTGRESQL_*). We need a script to bridge these variables into the format expected by Syncstorage-RS.

cloudron-entrypoint.sh:

#!/bin/bash
set -eu

# Default values
SYNC_HOST="${SYNC_HOST:-0.0.0.0}"
SYNC_PORT="${SYNC_PORT:-8000}"
SYNC_MASTER_SECRET="${SYNC_MASTER_SECRET:-}"

# 1. Detect Cloudron PostgreSQL addon
if [ -z "${CLOUDRON_POSTGRESQL_HOST:-}" ]; then
    echo "Error: PostgreSQL addon not found. Please ensure it is installed." >&2
    exit 1
fi

# 2. Convert Cloudron vars to Syncstorage connection strings
# We use the same DB for both storage and token management
POSTGRES_USER="${CLOUDRON_POSTGRESQL_USERNAME}"
POSTGRES_PASSWORD="${CLOUDRON_POSTGRESQL_PASSWORD}"
POSTGRES_HOST="${CLOUDRON_POSTGRESQL_HOST}"
POSTGRES_PORT="${CLOUDRON_POSTGRESQL_PORT}"
POSTGRES_DATABASE="${CLOUDRON_POSTGRESQL_DATABASE}"

export SYNC_SYNCSTORAGE__DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE}"
export SYNC_TOKENSERVER__DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE}"
export SYNC_TOKENSERVER__RUN_MIGRATIONS="true"

# 3. Validate required config
if [ -z "$SYNC_MASTER_SECRET" ]; then
    echo "Error: SYNC_MASTER_SECRET must be set in the Cloudron Environment tab." >&2
    exit 1
fi

# 4. Start the application
exec /app/bin/syncserver "$@"

---

3. Adapt the Dockerfile (Dockerfile.cloudron)

The original Dockerfile often uses modern features like Docker BuildKit (e.g., --mount=type=cache or --chmod in COPY) which might not be supported in all environments. We created a "clean" version that works with standard Docker.

Key Changes Made:

1. Set Defaults: Set SYNCSTORAGE_DATABASE_BACKEND and TOKENSERVER_DATABASE_BACKEND to postgres at the top of the file.
2. Remove BuildKit mounts: Removed all instances of --mount=type=cache... from RUN commands to allow building without BuildKit enabled.
3. Remove inline chmod: Changed COPY --chmod=0755 to standard COPY followed by a RUN chmod +x command.
4. Inject Start Script: Added the cloudron-entrypoint.sh and set it as the ENTRYPOINT.

Fragment of changes in the final stage:

# ... after all builds ...
COPY --from=builder /app/bin /app/bin
COPY cloudron-entrypoint.sh /app/cloudron-entrypoint.sh

# BuildKit-compatible chmod replacement
RUN chmod +x /app/cloudron-entrypoint.sh

USER app:app
ENTRYPOINT ["/app/cloudron-entrypoint.sh"]

---

4. Building and Pushing

To build the image using the new Dockerfile and push it to Cloudron:

# 1. Build locally
docker build -f Dockerfile.cloudron -t syncstorage-rs:cloudron .

# 2. Push to Cloudron Registry
docker tag syncstorage-rs:cloudron CLOUDRON_IP:5000/syncstorage-rs:cloudron
docker push CLOUDRON_IP:5000/syncstorage-rs:cloudron

---

5. Summary of logic

1. Single Container: We package the Rust binary and its Python dependencies into one image.
2. PostgreSQL Integration: Instead of separate containers for Sync and Token databases, we point both services to the single PostgreSQL database provided by Cloudron.
3. Auto-Migrations: We set SYNC_TOKENSERVER__RUN_MIGRATIONS="true" so the database schema is created automatically on the first start.
4. Security: The SYNC_MASTER_SECRET is the only manual configuration required, ensuring data is encrypted at rest.

Well, there are 44 services, so I don't really want to select and de-select them in varying configurations.

I would add an app list somewhere, that's the suggestion I have made above.

The bug is fixed now! But I still don't get the per-app overview. When I choose all apps and services, I still see the tops only.

So, doable, sure, but maybe someone else wants this feature as well, so we can leave this open.

Right, I didn't use this yet because of the bad user experience (sorry!).
In particular:

• When I select/unselect apps, I need to update the timeframe for the changes to have effect. This is a bug, it should update immediately.
• Most importantly, though, I wouldn't put this on hover, the list is long in my case and the numbers are very hard to read. The list is unsorted as well.

I guess the feature request would be to make this a separate section with basic table functions (filtering, sorting, searching). This would be a great UI win.

@timconsidine said in Staging environment for custom apps:

@ekevu123 I think we have a different understanding of staging.
No point in testing an app before promotion without real data.

Sure. I assumed you wanted to say that you install a second app, and then swap domains between the original and second app, which would mean that the second app without the data becomes production.

Maybe I misunderstood?

Yes, getting a quick overview of all apps for comparison. I don't see any specific apps in the system-wide stats/graphs, maybe because there's no outlier.

Precisely, I'd like to see whether there's an app using too many ressources, RAM in my case, without accessing every single one of each. I wouldn't need to know only the top apps, because that might be justified.

@timconsidine If you use the cloudron database add-on, the data wouldn't be transferred this way.

@nebulon said in Staging environment for custom apps:

I am not 100% sure what the proposed solution here is, but sounds like a simple shell script wrapper around the cloudron cli achieves that already?

Essentially this would be:

1. backup prod app
2. clone from prod backup to staging
3. update stating app instance
4. test
5. if test is good, update the prod app

Is there anything missing from this?

I can't say for sure, I kind of wanted to start a discussion first and see if other users have the same problem.

I have just realised there's no per-app breakdown of server ressource usage in the UI, unless one app is big enough to appear in the overall statistics.

But I think it could be helpful to understand quickly which app uses how much space, which app uses the most RAM etc.