Page tree
Skip to end of metadata
Go to start of metadata


  • Time and lack of expertise is keeping people to run Magnolia in Docker and / or Kubernetes.
  • No documentation on dockerizing Magnolia
  • Request for a how-to / Magnolia-Dockerfiles

  • Restoring MySQL-Data whilst starting Magnolia-Docker-Images locally
    • Storing everything in the database (including assets) might be easier for spinning up new database instances (in terms of scaling)
  • S3-Adapter / connector for assets

  • Autoscaling for Magnolia Public instances
    • Complex because of license issues
    • Most devs starting new public instances by hand
    • There is a need for unlimited license if you do autoscaling
    • Configuration (for example add subscribes) for new started Magnolia instances could be done via Magnolia REST-API

  • Every new version built by developers generates a new Docker image
  • Base image for Magnolia based sites

  • Azure SQL / Google Cloud SQL
    • Rate Limiting leads to queueing
    • Vertical scaling for databases

  • Demand for showing / deleting version history

  • Managing data and scaling in modern cloud environments is still complicated

Technologies & popularity:

  • Docker, used by many (star)(star)(star)
  • Packer (
  • Kubernetes, more for orchestration than for scalability (star)(star)
  • Docker Compose, for local development (star)
    • Some went back to starting Magnolia locally because of the poor Docker performance on Apple hardware
  • Docker Swarm
  • Ansible (star)
  • SaltStack
  • GitLab CI
  • Terraform
  • ZooKeeper

Session-Management for multiple Public-Instances:

  • Sticky Sessions managed in the Loadbalancer
  • Redis to store session data (only works in the same region)
  • Try to avoid having state in the Backend (requires decoupling frontend from the backend)


Magnolia SRE's base docker image: