Podman-compose setup for Fresco

Hello, we are a small university team that needs to run Fresco self-hosted for security reasons. We also don’t have access to docker but we are able to use podman. I have translated the docker-compose from the advanced deployment how to page into a podman-compose file that is working and sets up the fresco and postgresql containers properly and the internal URL is working. However, I am simply faced with this generic error and none of the buttons work to tell me the errors in more detail (see image). Do you have any suggestions as to what might be going wrong or how to find out more?

Hi!

First of all, thanks for your interest in the project, and kudos for having the technical chops to set this all up with podman! This is the first attempt to use a different container runtime, I think!

Apologies that the error message isn’t that useful - we do this for security reasons (so that participants don’t get exposed to the internal workings of the app). When you deploy to vercel, you can see these logs from their dashboard. For podman, you should be able to see the error message by using:

podman logs <container_name_or_id>

You can add -f to “tail” the logs so you can see them update in realtime.

I’m going to try to recreate your setup just to make sure that there aren’t any obvious issues on our side. Will let you know what I find.

Okay @cu-tech I did some work on this today, and found the following:

  • There are some required changes to the compose file to use podman-compose:
    • Random host port is not supported (0:3000) so you need to specify a host port.
    • Need to use the :Z option for the postgres volume to enable SELinux relabeling for rootless Podman
  • The core issue I found: podman-compose doesn’t support the depends_on property, or the service_healthy condition.
    • This means that the app and the database start at the same time, and the app crashes because it can’t connect to the database.
    • The only solution I can offer is to start the services sequentially via a bash script:
  # Start postgres first
  podman-compose -f podman-compose.prod.yml up -d postgres

  # Wait for it to be healthy
  sleep 10

  # Then start fresco
  podman-compose -f podman-compose.prod.yml up fresco

It is very likely that the issue you were experiencing was caused by this, but if not please let me know and I’ll help you debug.

Thank you so much! This is extremely helpful and we are very appreciative. We are going to try it all today so I will reply with how it went soon.

Okay, after trying today we are closer but still not past the previous point. Your suggestions and script was very helpful but something is still going wrong where podman doesn’t recognize that the database has been created yet despite the separation in their creation.

[postgres] | PostgreSQL Database directory appears to contain a database; Skipping initialization
[postgres] |
[postgres] | 2025-11-18 19:55:02.560 UTC [1] LOG: starting PostgreSQL 16.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit
[postgres] | 2025-11-18 19:55:02.562 UTC [1] LOG: listening on IPv4 address “0.0.0.0”, port 5432
[postgres] | 2025-11-18 19:55:02.563 UTC [1] LOG: listening on IPv6 address “::”, port 5432
[postgres] | 2025-11-18 19:55:02.573 UTC [1] LOG: listening on Unix socket “/var/run/postgresql/.s.PGSQL.5432”
[postgres] | 2025-11-18 19:55:02.599 UTC [24] LOG: database system was shut down at 2025-11-18 19:55:00 UTC
[postgres] | 2025-11-18 19:55:02.623 UTC [25] FATAL: the database system is starting up
[postgres] | 2025-11-18 19:55:02.648 UTC [1] LOG: database system is ready to accept connections
[postgres] | 2025-11-18 19:55:08.462 UTC [31] FATAL: database “ibs-fresco” does not exist
[postgres] | 2025-11-18 19:55:14.466 UTC [33] FATAL: database “ibs-fresco” does not exist

Our compose file looks like this (with the password and URL changed for public posting):

version: “3.9”

services:
fresco:
image: Package fresco · GitHub
environment:
DATABASE_URL: postgresql://ibs-fresco:Test12345!@postgres:5432/fresco
DATABASE_URL_UNPOOLED: postgresql://ibs-fresco:Test12345!@postgres:5432/fresco
PUBLIC_URL: https://test.test.com
depends_on:

  • postgres
    volumes:
  • .:/app/next-app:Z
    restart: always
    ports:
  • “3000”
    networks:
  • fresco_network

postgres:
image: postgres:16-alpine
restart: always
environment:
POSTGRES_DB: fresco
POSTGRES_USER: ibs-fresco
POSTGRES_PASSWORD: Test12345!
volumes:

  • postgres:/var/lib/postgresql/data:Z
    healthcheck:
    test: [“CMD-SHELL”, “pg_isready -U $${POSTGRES_USER}”]
    interval: 5s
    timeout: 10s
    retries: 5
    networks:
  • fresco_network

volumes:
postgres:

networks:
fresco_network:

We will keep testing this week and let you know how things are going. Thank you again very much for your help.

What you’ve posted above doesn’t make sense to me. Postgres is complaining that something is trying to connect to a database called ibs-fresco but there’s no reference to that in your compose file. It just isn’t possible.

Do you have the application container (fresco) still running from a previous attempt? What is the output of podman ps -a? Are you running any other postgres monitoring tools that might be trying to connect to that database?

It also looks like there are some other errors in your compose file, but those might have been introduced by you trying to hide sensitive info.

Make sure you delete any volumes from when you have tried to set this up previously.

This is a fully functioning compose file:

services:
  fresco:
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@postgres:5432/postgres
      - DATABASE_URL_UNPOOLED=postgresql://postgres:postgres@postgres:5432/postgres
      - PUBLIC_URL=https://mywebsite.com
      - UPLOADTHING_TOKEN='token'
    image: 'ghcr.io/complexdatacollective/fresco:latest'
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - .:/app/next-app
    restart: always
    ports:
      - 3000:3000
    networks:
      - fresco_network

  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    volumes:
      - postgres:/var/lib/postgresql/data:Z
    healthcheck:
      test: ['CMD', 'pg_isready', '-U', 'postgres']
      interval: 5s
      timeout: 10s
      retries: 5
    networks:
      - fresco_network

volumes:
  postgres:

# Define a network, which allows containers to communicate
# with each other, by using their container name as a hostname
networks:
  fresco_network:

Bring the services up one at a time:

podman-compose -f compose.yml up -d postgres 

then after a few seconds:

podman-compose -f compose.yml up -d fresco 

thank you! we got it working with that compose file. the manual start with the two consecutive commands didn’t work in our environment but podman-compose up -d did it. thank you so much for your help!

1 Like

Hi Joshua,

We have our containers up and running and can see the fresco error page but we are unable to locate the log files and make any progress past this page:

Here is our debug info:
Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.
Path: /dashboard
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36
Stack Trace:
Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.

Do you know where these log files would be or what might be the issue causing this page to pop up?

(We are still using your podman-compose file from above, just without alpine)

The logs will be in the app container itself, as per my previous reply about this. You can see them via podman logs

I understand, but unfortunately that location is blank for the fresco container. The postgres container contains logs at this location but not the fresco container.