https://casibase.org/docs/basic/try-with-docker/

[giscus[bot]]

https://casibase.org/docs/basic/try-with-docker/

Try Casibase with Docker

https://casibase.org/docs/basic/try-with-docker/

[matteolavaggi]

I've search in the docs with no luck, i've a simple question, how can i start casibase docker image with cadoor local path reference? Login page always point to https://door.casdoor.com/ .
I've try using ENV variable for casdoor url AND app.conf sample with the same result.

Here a snippet of dev setup app.conf file

appname = casibase
httpport = 14000
runmode = dev
SessionOn = true
copyrequestbody = true
driverName = mysql
dataSourceName = root:123456@tcp(db:3306)/
dbName = casibase
redisEndpoint =
guacamoleEndpoint = 127.0.0.1:4822
isDemoMode = false
disablePreviewMode = false
logPostOnly = true
landingFolder =
casdoorEndpoint = http://casdoor:8000
clientId = c7996278a05559751d18
clientSecret = ddf7f830b50d04db9c4359fa4e7d419477bff688
casdoorOrganization = "casibase"
casdoorApplication = "casibase"
redirectPath = /callback
cacheDir = "C:/casibase_cache"
appDir = ""
isLocalIpDb = false
audioStorageProvider = ""
providerDbName = ""
socks5Proxy = "127.0.0.1:10808"
publicDomain = ""
adminDomain = ""
enableExtraPages = false
shortcutPageItems = []
usageEndpoints = []
iframeUrl = ""
forceLanguage = ""
defaultLanguage = "en"
staticBaseUrl = "https://cdn.casibase.org"
htmlTitle = "Casibase"
faviconUrl = "https://cdn.casibase.com/static/favicon.png"
logoUrl = "https://cdn.casibase.org/img/casibase-logo_1200x256.png"
navbarHtml = ""
footerHtml = "Powered by <a target="_blank" href="https://github.com/casibase/casibase" rel="noreferrer"><img style="padding-bottom: 3px;" height="20" alt="Casibase" src="https://cdn.casibase.org/img/casibase-logo_1200x256.png" /></a>"
appUrl = ""
frontendBaseDir = "../casibase"
showGithubCorner = false
defaultThemeType = "default"
defaultColorPrimary = "#5734d3"
defaultBorderRadius = 6
defaultIsCompact = false
avatarErrorUrl = "https://cdn.casibase.org/gravatar/error.png"
logConfig = {"adapter":"file", "filename": "logs/casibase.log", "maxdays":99999, "perm":"0770"}

docker file

version: "3.8"

services:
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: casdoor
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    networks:
      - casibase_network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 10

  casdoor:
    image: casbin/casdoor:latest
    restart: always
    ports:
      - "8000:8000"
    depends_on:
      db:
        condition: service_healthy
    environment:
      RUNNING_IN_DOCKER: "true"
    volumes:
      - ./conf:/conf
    networks:
      - casibase_network

  casibase:
    image: casbin/casibase-all-in-one:latest
    restart: always
    ports:
      - "14000:14000"
    depends_on:
      - casdoor
    environment:
      RUNNING_IN_DOCKER: "true"
    volumes:
      - ./app.conf:/conf/app.conf
    networks:
      - casibase_network

volumes:
  mysql_data:

networks:
  casibase_network:
    driver: bridge

[hsluoyz]

Hi @matteolavaggi , see the docs for self-hosted Casdoor: https://casibase.org/docs/basic/server-installation#custom-configuration

[matteolavaggi]

I'll reply with a comprensive report here:

Docker Setup Issues: All-in-One Image Fails + Documentation Gaps + Casdoor URL Configuration Problem

Summary

The Docker setup for Casibase has three critical issues that prevent the "quick start" experience advertised in the documentation. These issues make Docker deployment more time-consuming than installing from source, which defeats the purpose of providing Docker images.

---

Issue 1: All-in-One Image Fails to Start

Severity: Critical
Expected Behavior: Running docker run -p 14000:14000 casbin/casibase-all-in-one should start Casibase with a toy database as advertised in the documentation.

Actual Behavior:

docker run -p 14000:14000 casbin/casibase-all-in-one
Starting MariaDB database server: mariadbd ..
panic: dial tcp 172.17.0.1:3306: connect: connection refused

goroutine 1 [running]:
github.com/casibase/casibase/object.CreateTables()
	/go/src/casibase/object/adapter.go:74 +0x47
main.main()
	/go/src/casibase/main.go:35 +0x45

Root Cause: The container starts the application before MariaDB is fully initialized, and the application attempts to connect to 172.17.0.1:3306 instead of localhost:3306.

Proposed Solutions:

1. Fix the all-in-one image by adding proper startup sequencing that waits for MariaDB to be ready
2. OR remove the all-in-one image entirely if it cannot be made reliable

Impact: Users following the documentation cannot test Casibase using the recommended "quick start" method.

---

Issue 2: Documentation Structure - Casdoor Requirement Buried

Severity: Major
Current State: The Casdoor SSO requirement is mentioned as the 9th topic in the documentation, after users have already attempted installation.

Problem: Users cannot successfully run Casibase (with Docker or otherwise) without Casdoor already deployed, yet this critical dependency is not mentioned upfront.

Current Documentation Structure:

1. Overview
2. Core Concepts
3. Server Installation
4. (Optional) Try with Docker
5. (Optional) Try with K8s Helm
6. Casibase Public API
7. Container Cloud
8. Beginner Guide
9. Casdoor-SSO ← Critical dependency buried here!

Proposed Documentation Structure:

1. Overview
2. Core Concepts
3. Prerequisites & Dependencies
   ├─ Casdoor-SSO Setup (REQUIRED - move from position 9)
   └─ Database Requirements
4. Server Installation
5. (Optional) Try with Docker
6. (Optional) Try with K8s Helm
7. Casibase Public API
8. Container Cloud
9. Beginner Guide

Rationale:

• Casdoor is a hard requirement, not optional
• Must be deployed before attempting any Casibase installation method
• Current position (topic 9) causes users to:
  1. Attempt Docker/server installation
  2. Encounter authentication errors
  3. Search documentation to discover Casdoor requirement
  4. Start over with Casdoor setup first

Proposed Solution:

• Create a new "Prerequisites & Dependencies" section before installation methods
• Move Casdoor-SSO content to this new section
• Add a prominent warning in Docker/Installation sections linking to prerequisites
• Mark Casdoor as REQUIRED (not optional) in all relevant sections

---

Issue 3: Casdoor URL Configuration - Internal vs External Access

Severity: Major
Setup Context: Docker Compose with 3 containers:

• casibase (port 14000)
• casdoor (port 8000)
• db (MySQL/MariaDB)

The Problem:
Casibase needs two different URLs for Casdoor, but the configuration only allows one:

1. Internal URL (Docker network): http://casdoor:8000

   • Required for Casibase container to communicate with Casdoor during startup
   • Works within Docker network

2. External URL (User browser): http://localhost:8000

   • Required for user authentication redirects
   • Browser cannot resolve http://casdoor:8000

Current Behavior:

• If configured with http://casdoor:8000: ✅ Container starts, ❌ Login redirects fail (browser can't resolve casdoor)
• If configured with http://localhost:8000: ❌ Container fails to start (container can't resolve localhost as Casdoor), ✅ Login redirects would work

Current Workaround:
Add to /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows):

127.0.0.1 casdoor

Then configure Casibase with http://casdoor:8000, which allows:

• ✅ Casibase container to start (resolves casdoor via Docker network)
• ✅ User browsers to access login (resolves casdoor via hosts file to localhost)

Proposed Solutions:

1. Add separate configuration parameters in app.conf:

   # For container-to-container communication
   casdoorInternalUrl = http://casdoor:8000
   
   # For browser redirects
   casdoorExternalUrl = http://localhost:8000

2. OR document the hosts file workaround prominently in the Docker setup guide with clear instructions for all operating systems

3. OR provide a working docker-compose.yml example that properly handles this scenario using:

   • host.docker.internal
   • Network aliases
   • Reverse proxy configuration

4. OR use environment variable substitution to allow different URLs:

   docker run \
     -e CASDOOR_INTERNAL_URL=http://casdoor:8000 \
     -e CASDOOR_EXTERNAL_URL=http://localhost:8000 \
     casbin/casibase

Missing Configuration:
I've searched both app.conf and the documentation but found no way to specify separate internal/external URLs for Casdoor. This is a critical missing feature for Docker deployments.

---

Environment

• Host OS: macOS (but issue affects all platforms)
• Docker Version: Latest
• Image: casbin/casibase-all-in-one:latest

Additional Context

These issues significantly impact the "quick start" experience. A proper Docker setup should be simpler than source installation, but currently it requires:

• Debugging startup scripts
• Understanding Docker networking intricacies
• Manual hosts file modifications
• Reading through 9 documentation sections before discovering critical dependencies

This defeats the purpose of providing Docker images for easy evaluation.

Impact Summary

• Issue 1: Blocks all users from using the "quick start" all-in-one image
• Issue 2: Wastes user time by not documenting prerequisites upfront
• Issue 3: Requires undocumented system-level configuration changes for Docker networking

---

Related Documentation:

• https://casibase.org/docs/basic/try-with-docker
• https://github.com/casibase/casibase/blob/master/docker-compose.yml

Issue 4: Docker Compose Option Requires Source Code (Defeats "Try with Docker" Purpose)

The official docker-compose.yml uses:

build:
  context: ./
  dockerfile: Dockerfile
  target: STANDARD

This means:

• ❌ Users need to clone the entire repository
• ❌ Users need to build the image themselves (requires 2GB+ RAM)
• ❌ Defeats the purpose of "Try with Docker" (should be quick/easy)
• ❌ Not using the pre-built casbin/casibase images

This is a fundamental flaw in the documentation.

Severity: Critical (Design Flaw)
Location: https://casibase.org/docs/basic/try-with-docker - Option-2

Current Documentation Says:

Option-2: Try with docker-compose

Create a conf/app.conf directory in the same directory level as the docker-compose.yml file. Then, copy app.conf from Casibase.

Create a separate database using docker-compose:

docker-compose up

Critical Problems:

1. No docker-compose.yml file provided - Documentation references a file but never provides it or links to it

2. Official docker-compose.yml requires source code - The file at https://github.com/casibase/casibase/blob/master/docker-compose.yml contains:

   build:
     context: ./
     dockerfile: Dockerfile
     target: STANDARD

   This means users must:

   • Clone the entire Casibase repository
   • Have 2GB+ RAM to build the frontend
   • Wait for a full Docker image build
   • This defeats the entire purpose of "Try with Docker"

3. Missing Casdoor service - Even the official docker-compose.yml doesn't include Casdoor (which is required)

What "Try with Docker" Should Mean:

• ✅ Use pre-built images from Docker Hub
• ✅ No source code required
• ✅ Quick setup (minutes, not hours)
• ✅ All dependencies included (database + Casdoor)

What It Actually Requires:

• ❌ Clone git repository
• ❌ Build from source
• ❌ Manually setup Casdoor separately
• ❌ Complex configuration

Proposed Solution:

Option A: Provide a proper docker-compose.yml using pre-built images

Create and document a complete docker-compose.yml that:

version: '3.8'

services:
  db:
    image: mysql:8.0.25
    # ... with health checks and ping waiting timeout

  casdoor:
    image: casbin/casdoor:latest
    # ... properly configured

  casibase:
    image: casbin/casibase:latest  # ← Use pre-built image!
    # ... properly configured with Casdoor URLs (see previous issue)

Option B: Remove Option-2 entirely

If a working docker-compose with pre-built images cannot be provided, remove this option and only keep:

• Option-1: All-in-one image (after fixing Issue Add settings pages using react. #1)
• Option-3: Standard image with external database

Option C: Rename to "Build from Source with Docker"

If the intention is to build from source, rename this section to clarify:

• "Option-2: Build from Source using docker-compose"
• Move it to an "Advanced" or "Development" section
• Don't position it as a "quick try" option

Impact:

• Users attempting "Try with Docker" are forced to clone source and build
• This is slower and more complex than just installing from source normally
• Completely defeats the advertised purpose of quick Docker evaluation
• Creates confusion about what "Try with Docker" means

Recommendation:
The "Try with Docker" section should use only pre-built images. Source builds belong in a separate "Development Setup" or "Build from Source" section.

[FlySky-z]

Hello,

Thank you for raising these questions and suggestions. I tried to reproduce the issue based on the information you provided, but I haven't encountered the Casdoor problem you mentioned so far. You may want to update your Docker image to the latest version and double-check whether the app.conf path is configured correctly.

If you're familiar with Docker, you could try entering the Casibase container and verify whether the app.conf file has been properly mounted. This will help determine whether the issue lies in Docker volume mounting or within the application itself.

Additionally, regarding the all-in-one image: it already includes an embedded MariaDB instance, so no external database is required. This image is primarily intended for quick evaluation and testing purposes. For Docker Compose deployments, we recommend using the standard Casibase image instead.

One point that our documentation may not have clearly emphasized is that Casdoor is a standalone application. You need to first create an application within Casdoor, and then use the clientId and clientSecret provided by Casdoor to configure Casibase's app.conf file accordingly.

In summary, when deploying via Docker Compose, it's perfectly feasible to deploy the database (db) alongside Casibase—just use the standard Casibase image. Casdoor, however, should be deployed separately, as you must first create an application in Casdoor to obtain the necessary clientId and clientSecret for Casibase configuration.

[matteolavaggi]

Hi, thanks for your reply but i need to ask you some questions:

A. wich of the "try with docker" option have you tested with success?

Option-1: Use the toy database
docker run -p 14000:14000 casbin/casibase-all-in-one

This definitely not work. The Embed mariadb database start too late to allow container to biuld up:

'''bash
matteolavaggi@MacBookPro16 casibase % docker run -p 14000:14000 casbin/casibase-all-in-one
Starting MariaDB database server: mariadbd ..
panic: dial tcp 172.17.0.1:3306: connect: connection refused

goroutine 1 [running]:
github.com/casibase/casibase/object.CreateTables()
/go/src/casibase/object/adapter.go:74 +0x47
main.main()
/go/src/casibase/main.go:35 +0x45
matteolavaggi@MacBookPro16 casibase %
'''

As you can see the direct docker run command DOES not allow to run the container.
So to fix this you need to add timeout logic to the image to allow mariadb to be reached during container creation.

==> This is a bug of the casibase-all-in-one image , you can fix it or remove from the docs to avoid confusion.
If you where able to run the Option 1. please provide a bash trace of the container biuld up from the basic command, i've try on windows 11 and mac using last docker available, with the same result.

To fix this you must upadte the all in one image to use some waiting logic against mariadb, something like

'''bash
#!/bin/bash

Start MariaDB

service mariadb start

Wait for MariaDB to be ready

until mysqladmin ping -h"127.0.0.1" --silent; do
echo 'Waiting for MariaDB to be ready...'
sleep 2
done

echo 'MariaDB is ready!'
'''

---

Issue with "Option-2: Try with docker-compose" Documentation

The current documentation at [Option-2: Try with docker-compose](https://casibase.org/docs/basic/try-with-docker/#option-2-try-with-docker-compose) has several critical issues that confuse end users:

Problems Identified:

1. No docker-compose.yml template provided in documentation

   • Users are told to create a conf/app.conf file and run docker-compose up, but there's no template file to use
   • If users search the main repo and find [docker-compose.yml](https://github.com/casibase/casibase/blob/master/docker-compose.yml), they'll unknowingly trigger a full development build from source instead of using the pre-built Docker images

2. Documentation mixes two different use cases:

   • Testing/Production: Using pre-built images from Docker Hub (casbin/casibase)
   • Development: Building from source code with the repo's docker-compose.yml

   The current docs appear to be for testing but reference development files, causing confusion.

3. Missing service dependencies and orchestration:

   • No mention of Casdoor (which Casibase requires)
   • No proper wait mechanisms or health checks between services
   • Users will encounter race conditions where Casibase starts before the database is ready

4. Incomplete configuration instructions:

   • Both Casdoor and Casibase require their own app.conf files
   • Current docs only mention creating one conf/ directory, which is ambiguous
   • Users need both:
     • [Casdoor's app.conf](https://github.com/casdoor/casdoor/blob/master/conf/app.conf)
     • [Casibase's app.conf](https://github.com/casibase/casibase/blob/master/conf/app.conf)

Proposed Solution:

1. Directory Structure

Provide clear instructions to create separate configuration directories:

project/
├── docker-compose.yml
└── conf/
    ├── casdoor/
    │   └── app.conf    (from Casdoor repo)
    └── casibase/
        └── app.conf    (from Casibase repo)

2. Production-Ready docker-compose.yml Template

version: '3.8'

services:
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: casdoor
    volumes:
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 5s
      retries: 10

  casdoor:
    image: casbin/casdoor:latest
    restart: always
    depends_on:
      db:
        condition: service_healthy
    environment:
      RUNNING_IN_DOCKER: "true"
    ports:
      - "8000:8000"
    volumes:
      - ./conf/casdoor:/conf

  casibase:
    image: casbin/casibase:latest
    restart: always
    depends_on:
      db:
        condition: service_healthy
      casdoor:
        condition: service_started
    environment:
      RUNNING_IN_DOCKER: "true"
    ports:
      - "14000:14000"
    volumes:
      - ./conf/casibase:/conf

volumes:
  mysql_data:

3. Step-by-Step Setup Instructions

The documentation should include:

1. Create the directory structure:

   mkdir -p conf/casdoor conf/casibase

2. Download configuration files:

   # Download Casdoor config
   curl -o conf/casdoor/app.conf https://raw.githubusercontent.com/casdoor/casdoor/master/conf/app.conf
   
   # Download Casibase config
   curl -o conf/casibase/app.conf https://raw.githubusercontent.com/casibase/casibase/master/conf/app.conf

3. Modify both config files to set database connection strings appropriately for Docker networking (service name db instead of localhost)

4. Run docker-compose:

   docker-compose up -d

Additional Recommendations:

1. Clearly separate documentation sections:

   • "Quick Start (Pre-built Images)" - for users who want to test/deploy
   • "Development Setup" - for contributors who want to build from source

2. Fix the explanation about RUNNING_IN_DOCKER:

   • The current note mentions host.docker.internal, which doesn't work reliably on Linux
   • With proper docker-compose networking, services should reference each other by service name (e.g., db:3306, not localhost:3306)

3. Provide a complete working example with proper configuration management for both services

---

B. Im still haveing trouble to use casdoor in docker, as i've written before its impoosible to use a single url to contact casdoor from docker AND to redirect user to login in frontend. One or the other will fail resolving!

Using in casibase app.conf this casdoorEndpoint = http://localhost:8000 will result in casibase image not able to boot because it cant find localhost:8000 from docker.

Using casdoorEndpoint = http://casdoor:8000 will result in frontend user redirected to not resolved host because casdoor:8000 are not reachable from localhost, only inside docker .

[FlySky-z]

Hello, thank you very much for pointing out this issue. After investigation, I found that the problem with Option-1: Use the toy database occurs because, after adding the RUNNING_IN_DOCKER environment variable, the application automatically replaces the default localhost with the IP address of Docker's default docker0 bridge (typically 172.17.0.1). However, the embedded database is not exposed externally, leading to a connection failure.

Thanks again for your report—I've already submitted a PR#1646 to fix this issue, and the documentation will also be updated as soon as possible. We truly appreciate your contribution!

[FlySky-z]

We have updated the documentation regarding "try with docker-compose."