How to Deploy CodiMD
Introduction
CodiMD is an open-source collaborative markdown editor. Deploying CodiMD on Klutch.sh provides scalable, secure infrastructure for collaborative note-taking, with support for persistent storage and automated CI/CD.
This guide covers deploying CodiMD on Klutch.sh using a Dockerfile, configuring persistent storage, and best practices for production deployments.
Prerequisites
- A Klutch.sh account (sign up here)
- A GitHub repository for your CodiMD deployment (or fork of the CodiMD repo)
- Basic knowledge of Docker and markdown concepts
1. Prepare your CodiMD repository
- Fork or clone the CodiMD repository, or create a wrapper repo for your customizations.
- Store large assets (such as configuration files, logs, or database files) outside the Git repo; use persistent volumes or object storage and mount or fetch them at runtime.
Refer to the Klutch.sh Quick Start Guide for repository setup and GitHub integration.
2. Sample non-Docker deployment (Klutch.sh build)
You can deploy CodiMD from your repo without a Dockerfile using Klutch.sh’s build system:
- Push your repo to GitHub. Include a start script (for example:
start.sh) that installs dependencies and runs CodiMD. - In Klutch.sh, create a new project and app, and connect your repository.
- Set the start command to the script or CodiMD’s start command (example:
node app.js). - Attach persistent volumes for configuration, logs, or database files (see Volumes Guide).
- Set the app port to
3000(or your configured port). - Click “Create” to build and deploy.
Notes:
- Configure runtime secrets (database credentials, API keys) as environment variables in Klutch.sh.
- For advanced use, customize the start script to load assets from mounted volumes or object storage.
3. Deploying with a Dockerfile (recommended for reproducibility)
A Dockerfile ensures reproducible builds and full control over dependencies. Example:
FROM hackmdio/hackmd:latest
# Optional: Add custom configuration or plugins# COPY ./config /codimd/config
EXPOSE 3000For custom assets, mount persistent volumes or fetch from object storage at startup.
4. Persistent storage & volumes
CodiMD requires persistent storage for configuration, logs, and database files:
- Create a persistent volume in Klutch.sh and mount it to
/codimd/configor your chosen path. - Configure CodiMD (or your startup script) to read/write from the mounted path.
Example mount mapping in Klutch.sh app settings:
/codimd/config <- my-codimd-storageIf using object storage (S3-compatible), store credentials in environment variables and fetch assets at startup.
5. Environment variables and secrets
- Store database credentials, API keys, and other secrets in Klutch.sh environment variables (never in the repo).
- Use the Klutch.sh UI to mark secrets and prevent them from being logged.
6. Scaling, monitoring, and best practices
- Use health checks and readiness probes if supported by CodiMD.
- Monitor CPU, memory, and latency; scale instances as needed.
- Pin dependency versions and use multi-stage Docker builds for smaller images.
- Use CI to build and publish images, or let Klutch.sh build from your repo and tag releases.
- Restrict public access to endpoints; require authentication or place behind an API gateway.
Resources
Deploying CodiMD on Klutch.sh gives you a reproducible, scalable path to serve collaborative markdown editing applications. For advanced setups, you can add a startup script to fetch assets from S3, a multi-stage Dockerfile for smaller images, or CI/CD integration to automate builds and deployments.