Cloudron Forum

@james said in Notification being unhelpful:

Hello @ekevu123

Where did you see this log message?

In the main notifications of the server instance

@joseph said in Notification being unhelpful:

This is coming from porkbun - https://status.porkbun.com/ . They are having some service issues .

Oh, thank you, that wasn't clear!

I have just gotten this notification, possibly related to the upgrade to Cloudron 9.1.0, which happened at the same time:

Configuration error: Porkbun DNS error 400 {"status":"ERROR","message":"Create error: We were unable to create the DNS record."}

The problem is that this notification doesn't allow me to act on it. I see the domain, but which DNS record is meant? Why was it updated in the first place? Also, seemingly, everything works, so maybe the error was re-tried anyway?

This would be really nice to have, because it could replace a commercial option that you'd otherwise need to pay for.

I push code to gitea and mirror it to github, and I am actually happy with that setup. However, I want to define releases on github, and every mirror push overwrites these. Most likely because the mirroring uses force push, however, I don't see any option to change that behaviour.

Can I solve this somehow? Releases don't seem to be synchronised either, I'd be more than happy to have them defined on gitea as the source of truth and sync everything together, but that doesn't seem possible.

Thank you! I went with Github Actions for now because I don't really need to isolate it, it would be just nice-to-have.

I would like to see custom expiry dates (optionally) for the app passwords I set in my profile. I am using them sometimes for debugging, and it can happen that I even give one of it to AI, e.g. "use this to test to authenticate" when coding.

If I could set an expiry date a few hours from now, I wouldn't have to worry about cleanup.

I am using gitea on Cloudron and I am trying to set up a runner that automates the workflow of building a docker image for an app I am building. I wanted to solve this using actions.

However, the runner seems to need a separate image installed to build the docker image there. Now, I could probably install this as a custom app on Cloudron, but firstly I wanted to understand if there's an easier way of accomplishing this?

Otherwise, another option would be to use Github Actions.

EDIT: The gitea runner can't be installed on Cloudron, because it needs to be able to spawn containers.

Steps to reproduce:

1. Go to Profile
2. App Passwords section
3. Click on Add
4. Add a password using the same name and choose the same app as you already have

Expected behaviour:
A warning appears informing about the duplicate

Actual behaviour:
Nothing happens when I try to create that app password

I believe the goal is to implement this for compliance purposes.

If you are using a SMTP relay server, you could use their API to implement a custom tool. Postmark, for example, has anti-spam tools that should help.

Cloudron can already connect to different DNS providers via API. When I install a new app, for example, it can automatically add that new subdomain, which is neat, but also incomplete.

Feature request: Let me manage all DNS entries for all domains via Cloudron CLI (CRUD operations).

Cloudron CLI is heavily gated, so there's no security issue. But this would provide me one interface for this, and I can use multiple providers in the background, but I don't have to care about logging in, or different API configuration. I just know that whenever I want to make a change, I can quickly do this in the terminal using a familiar interface. This would allow me to always use the cheapest provider, because there is no added benefit anymore of having all domains in one place.

Shouldn't this be an add-on instead of a standalone app and therefore be a feature request, not in the app wishlist?

You might be on to something here. When I tried to set up a call with myself just now, the issue occurred, but when I switched to mobile hotspot, I could connect. It could be that the co-working I am usually in blocks this, and I didn't realise this pattern, so I assumed this was an irregular failure.
I'll test this again later, just to be sure, but you might have solved the mystery, thanks a bunch!

@james said in Mirotalk - Participants can't see each other 2:

Also, did you set SFU_SERVER=true in your /app/data/env file as suggested by @mirotalk?

Yes!

Not knowingly!

Did you check the data I sent via email?

I just wanted to see if anyone has an idea regarding this?

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.