こんにちは！デザインシステムとエンジニアリングの境界線を美しく溶かす、プロダクトデザイナーの先輩です。
普段、Figmaなどのクラウド型ツールを使っていると、「自分たちのデザインデータがどこに保存され、どう管理されているか」を意識することはほとんどありませんよね。しかし、セキュリティやプライバシーの観点から、オープンソースの本格的デザインツール「Penpot」をセルフホスト（自社サーバーやローカル環境への導入）して使いこなしたいという現場が急増しています。
今回は、セルフホスト版Penpotの心臓部である「PostgreSQLデータベース」にスポットを当てます。「データをどう守るか」「どう安全にバックアップし、未来へ引き継ぐか」という、プロトタイピング環境の根幹を支える極限の知見を、優しく紐解いていきましょう。
これをマスターすれば、サーバー障害への恐怖から解放され、チームの資産を完璧にコントロールできるようになりますよ。
—
1. PenpotとPostgreSQLの関係：なぜデータベースを知る必要があるのか？
Penpotは、フロントエンド（ClojureScript）とバックエンド（Clojure）、そしてデータベース（PostgreSQL）という非常にモダンで堅牢なスタックで構築されています。
Figmaと違い、セルフホスト版Penpotにおけるすべてのデザインデータ（コンポーネント、ページ、カラーパレット、ユーザー情報など）は、あなたが管理するPostgreSQLのコンテナ（またはサーバー）の中にすべて格納されます。
つまり、Penpotのバージョンアップで失敗したり、サーバーが突然吹き飛んだりしたとき、PostgreSQLのバックアップさえあれば、デザイン資産は100%安全に救出できます。逆に、ここを疎かにしていると、チームの数ヶ月分のデザインが消え去る悪夢を見ることに……。
そうならないための「守りの要」を、一緒に構築していきましょう。
—
2. 基礎セットアップ：Docker Compose環境の全体像
Penpotを立ち上げるとき、通常は公式が提供するDocker Composeを使用します。このとき、裏側でPostgreSQLがどのように動いているか、`docker-compose.yml`の該当部分を覗いてみましょう。
version: “3.8”
services:
penpot-postgres:
image: postgres:15-alpine
restart: always
environment:
- POSTGRES_DB=penpot
- POSTGRES_USER=penpot
- POSTGRES_PASSWORD=penpot_secret_password
volumes:
# データベースの永続化（ここが命綱！）
- penpot-postgres-data:/var/lib/postgresql/data
networks:
- penpot-network
volumes:
penpot-postgres-data:
ここで重要なのが、`volumes`で指定されている `penpot-postgres-data` です。コンテナをどれだけ破棄（`docker compose down`）しても、この名前付きボリュームが存在する限り、データベースの中身は消えません。
まずは、これが正しく設定されていることを確認してください。これがセルフホストの第一歩です。
—
3. データの生死を分ける：安全なダンプ（バックアップ）の取得方法
「よし、毎日バックアップを取るぞ」と思ったとき、単にコンテナをそのままコピーするのはNGです。データベースが書き込み処理を行っている最中にファイルをコピーすると、データが破損する（整合性が失われる）リスクがあります。
PostgreSQLから安全に、かつ確実にデータを抽出するには、コンテナ内部のユーティリティである `pg_dump` を使います。
手動でのバックアップコマンド
ターミナルを開き、以下のコマンドを実行してみてください。
docker exec -t penpot-postgres pg_dump -U penpot -d penpot > ./penpot_backup_$(date +%Y%m%d_%H%M%S).sql
- `docker exec -t penpot-postgres`: 稼働中のPostgreSQLコンテナ内でコマンドを実行します。
- `pg_dump -U penpot -d penpot`: PostgreSQLの標準バックアップツールを使い、`penpot`データベースの全データをSQL形式で出力します。
- `> ./penpot_backup_…sql`: ホスト側のカレントディレクトリに、タイムスタンプ付きのきれいなSQLファイルとして保存します。
これで、いつでも元の状態に戻せる「タイムカプセル」が手に入りました。
—
4. 自動化の極意：毎日のバックアップスクリプトを組む
手動で毎日コマンドを叩くのは、エンジニアの仕事ではありません。シェルスクリプトとCron（またはコンテナのスケジューラー）を組み合わせて、完全自動化レイヤーを作り上げましょう。
以下のスクリプトを `backup-penpot.sh` として保存してください。
!/bin/bash
エラーが発生したら即座にスクリプトを停止
set -e
設定変数
BACKUP_DIR=”/path/to/your/penpot/backups”
CONTAINER_NAME=”penpot-postgres”
DB_USER=”penpot”
DB_NAME=”penpot”
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE=”$BACKUP_DIR/penpot_db_$DATE.sql”
バックアップディレクトリが存在しない場合は作成
mkdir -p “$BACKUP_DIR”
echo “==> Penpotデータベースのバックアップを開始します: $DATE”
1. pg_dumpを実行してSQLファイルに出力
docker exec -t “$CONTAINER_NAME” pg_dump -U “$DB_USER” -d “$DB_NAME” > “$BACKUP_FILE”
2. 圧縮して軽量化
gzip “$BACKUP_FILE”
echo “==> バックアップが完了しました: ${BACKUP_FILE}.gz”
3. 30日以上前の古いバックアップを自動削除（ディスク肥大化防止）
find “$BACKUP_DIR” -name “penpot_db_.sql.gz” -mtime +30 -delete
echo “==> 古いバックアップのクリーンアップが完了しました。”
このスクリプトに実行権限を与え (`chmod +x backup-penpot.sh`)、Linuxの `crontab` に登録しておけば、毎夜眠っている間にデザイン資産が完璧に保護されます。
—
5. メジャーバージョンアップ時のデータ移行（マイグレーション）の注意点
Penpot本体のバージョンアップに伴い、PostgreSQLのバージョンを上げなければならないケース（例: PostgreSQL 13から15への移行など）が出てきます。
ここで最もやってはいけないのが、「古いバージョンのボリュームデータを、新しいバージョンのPostgreSQLコンテナにそのまま直結させること」です。内部のデータ構造（ストレージフォーマット）が異なるため、起動時に致命的なエラーを起こします。
安全な移行のステップは以下の通りです。
1. 旧環境で完全バックアップを取得する
先ほどの `pg_dump` を使い、必ずSQL形式のダンプを取ります。
2. 新環境（新バージョン）をクリーンな状態で起動する
新しいボリュームを用意し、新しいPostgreSQLコンテナを立ち上げます。
3. データをリストア（復元）する
取得したSQLダンプを新しいデータベースに流し込みます。
新しいコンテナへデータを流し込むコマンド
docker exec -i new-penpot-postgres psql -U penpot -d penpot < ./penpot_backup_YYYYMMDD_HHMMSS.sql
この「Dump ＆ Restore」の原則を守るだけで、バージョンアップのトラブル起因によるデータ損失のリスクをゼロに抑えることができます。
—
おわりに：インフラを愛する者は、デザインを守る
今回は、PenpotのバックボーンであるPostgreSQLの内部構造と、現場で絶対に役立つバックアップ・移行戦略について解説しました。
「デザインツール」というと、どうしてもUI上の操作やコンポーネントの組み方に目が行がしまいがちです。しかし、チームのナレッジやアイデアが詰まったデータベースを安全にコントロールできるようになると、あなたのデザイン環境は「趣味やプロトタイプ用」から「実用に耐えうる堅牢なプロダクトインフラ」へと進化します。
これをマスターすれば、サーバーのメンテナンス日も、枕を高くしてぐっすり眠れますよ。
明日の開発・デザインライフが、より安心でクリエイティブなものになりますように！