OTA(Over-the-Air)アップデートを使えば、App Storeの審査を待たずにJavaScriptの変更、バグ修正、新機能をユーザーにプッシュできます。Expoのホスト型サービス(EAS Update)はよくできていますが、自己ホスティングには相応の理由があります:大規模なコスト管理、データ主権の要件、あるいは単にインフラを自分で所有したい場合です。
この記事では、Django REST FrameworkとTigris S3を使って自己ホスト型Expoアップデートサーバーを構築した方法を紹介します。私のCurtain EstimatorアプリでiOSとAndroidの両方にOTAアップデートを配信しているアーキテクチャです。
なぜExpoアップデートを自己ホスティングするのか?#
コスト管理#
EAS Updateの料金は使用量に応じて増加します。大規模なユーザーベースに頻繁にアップデートをプッシュする場合、Tigrisのような安価なS3互換ストレージでの自己ホスティングは確実にコストを節約できます。
データ主権#
一部の業界では、アプリケーションアセットの保存場所を完全に制御する必要があります。自己ホスティングにより、すべてのアップデートバンドルが自社のインフラに留まることが保証されます。
カスタムビジネスロジック#
特定のユーザーセグメントにアップデートを展開する必要がありますか?異なるバンドルでA/Bテストをしたいですか?カスタムサーバーなら、アップデートフロー全体を制御できます。
ベンダーロックインなし#
アップデートインフラがExpoのサービス可用性や価格変更に依存しません。
アーキテクチャ概要#
システムは4つの主要コンポーネントで構成されています:
- Djangoバックエンド:アップデートマニフェストを提供し、メタデータを保存
- Tigris S3ストレージ:実際のバンドルとアセットファイルをホスティング
- パブリッシングパイプライン:エクスポート、アップロード、アップデート登録を行うスクリプト
- モバイルアプリ:サーバーからアップデートを確認するよう構成
動作の仕組みは以下の通りです:
┌─────────────────┐
│ Mobile App │
│ (expo-updates) │
└────────┬────────┘
│ 1. Request manifest
│ (with headers: platform, runtime-version)
↓
┌─────────────────┐
│ Django Server │
│ /api/expo- │◄─── 2. Query DB for latest update
│ updates/ │
│ manifest/ │
└────────┬────────┘
│ 3. Generate presigned URLs
│
↓
┌─────────────────┐
│ Tigris S3 │
│ (Asset Files) │◄─── 4. App downloads bundles directly
└─────────────────┘実装の詳細#
Djangoモデル#
基盤となるのは2つのDjangoモデルです:ExpoUpdateとExpoUpdateAsset。
ExpoUpdateは各アップデートのメタデータを保存します:
class ExpoUpdate(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4)
runtime_version = models.CharField(max_length=50, db_index=True)
platform = models.CharField(
max_length=10,
choices=[("ios", "iOS"), ("android", "Android")],
db_index=True
)
is_active = models.BooleanField(default=True, db_index=True)
manifest_data = models.JSONField()
description = models.TextField(blank=True)
created_at = models.DateTimeField(auto_now_add=True)
class Meta:
indexes = [
models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
]主要な設計上の決定事項:
- runtime_version:
app.jsonのruntimeVersionと一致します。これは非常に重要です—クライアントは自身のランタイムバージョンに一致するアップデートのみをダウンロードします。 - platform:iOSとAndroidはバンドルが異なるため、別々のアップデートを使用します。
- is_active:問題のあるアップデートを無効化してロールバックをサポートします。
- manifest_data:完全なExpo Updates v1プロトコルマニフェストをJSONとして保存します。
ExpoUpdateAssetは個々のファイルを追跡します:
class ExpoUpdateAsset(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4)
update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE, related_name="assets")
hash = models.CharField(max_length=255, db_index=True)
key = models.CharField(max_length=255)
content_type = models.CharField(max_length=100)
file_extension = models.CharField(max_length=10)
file_path = models.CharField(max_length=500)
file_size = models.IntegerField(default=0)アセットはSHA-256ハッシュで参照され、不変でキャッシュ可能です。同じアセットを複数のアップデートで共有できます。
マニフェストエンドポイント#
/api/expo-updates/manifest/エンドポイントがシステムの中核です。Expo Updates v1プロトコルを実装しています。
@action(detail=False, methods=["get"], url_path="manifest")
def manifest(self, request):
# Extract required headers
protocol_version = request.META.get("HTTP_EXPO_PROTOCOL_VERSION")
platform = request.META.get("HTTP_EXPO_PLATFORM")
runtime_version = request.META.get("HTTP_EXPO_RUNTIME_VERSION")
# Validate protocol version
if protocol_version != "1":
return Response(
{"error": f"Unsupported protocol version: {protocol_version}"},
status=400
)
# Find latest active update for this runtime + platform
update = ExpoUpdate.objects.filter(
runtime_version=runtime_version,
platform=platform,
is_active=True,
).order_by("-created_at").first()
# No update available - client uses embedded bundle
if not update:
response = Response(status=204)
response["expo-protocol-version"] = "1"
return response
# Generate presigned URLs for all assets
manifest_data = self._generate_manifest_with_presigned_urls(update)
return Response(manifest_data, status=200)重要な詳細:
- 204 No Content:アップデートが見つからない場合、204を返します。アプリは組み込みバンドルを使用します。
- Presigned URL:アプリがTigris CDNから直接ダウンロードできる時間制限付きURLを生成します—Djangoを経由するプロキシよりはるかに高速です。
- ヘッダー:レスポンスに
expo-protocol-versionヘッダーが必須です。
アップデートのパブリッシング#
パブリッシングワークフローはDjango管理コマンドとシェルスクリプトラッパーで自動化されています。
管理コマンド(publish_expo_update.py)は以下を処理します:
expo exportの出力を読み取る- すべてのアセットのSHA-256ハッシュを計算
- バンドルとアセットをTigris S3に並列アップロード
- アップデートとアセットのデータベースレコードを作成
- オプションでプロダクション同期用のインポートJSONをアップロード
コアフローは以下の通りです:
def _publish_platform(self, platform, runtime_version, export_dir, ...):
# 1. Find the bundle file
bundle_files = list(bundle_dir.glob("entry-*.hbc"))
bundle_file = bundle_files[0]
# 2. Calculate hash
with open(bundle_file, "rb") as f:
bundle_content = f.read()
bundle_hash = self._calculate_hash(bundle_content)
# 3. Collect all assets and their hashes
for asset_file in assets_dir.rglob("*"):
# Calculate hash, determine content type...
assets_metadata.append({...})
# 4. Upload to S3 in parallel
with ThreadPoolExecutor(max_workers=10) as executor:
futures = {executor.submit(upload_asset, a): a for a in assets_metadata}
# 5. Create database records
with transaction.atomic():
# Deactivate previous updates
ExpoUpdate.objects.filter(
runtime_version=runtime_version,
platform=platform,
is_active=True
).update(is_active=False)
# Create new update
update = ExpoUpdate.objects.create(...)シェルスクリプト(publish-ota-update.sh)はユーザーフレンドリーなインターフェースを提供します:
# Publish to local environment
./scripts/publish-ota-update.sh ios
# Publish to production
./scripts/publish-ota-update.sh ios --production
# Dry run to validate
./scripts/publish-ota-update.sh --dry-run主な機能:
- プロダクション環境変数でアプリを自動エクスポート
- 速度向上のためアセットを並列アップロード
- プラットフォーム別またはマルチプラットフォームのアップデートをサポート
- APIエンドポイント経由でプロダクションに同期
APIを介したプロダクション同期#
プロダクションデプロイメントでは、システムは巧みな2段階プロセスを使用します:
- ローカルパブリッシュ:Tigrisにアセットをアップロードし、JSONスナップショットを作成
- リモートインポート:S3パスとともにプロダクションAPIを呼び出してメタデータをインポート
このアプローチにより、ローカルマシンにプロダクションの認証情報を置く必要がなくなります:
@action(detail=False, methods=["post"], url_path="import-update")
def import_update(self, request):
# Authenticate via Bearer token
secret = settings.OTA_IMPORT_SECRET
token = request.META.get("HTTP_AUTHORIZATION", "")[7:] # Strip "Bearer "
if not hmac.compare_digest(token, secret):
return Response({"error": "Invalid token"}, status=401)
# Download import JSON from Tigris
s3_key = request.data.get("s3_key")
obj = s3_client.get_object(Bucket=bucket_name, Key=s3_key)
data = json.loads(obj["Body"].read())
# Import to production database
with transaction.atomic():
ExpoUpdate.objects.update_or_create(id=data["id"], defaults={...})
for asset_data in data["assets"]:
ExpoUpdateAsset.objects.update_or_create(...)
# Clean up the import JSON
s3_client.delete_object(Bucket=bucket_name, Key=s3_key)モバイルアプリの設定#
app.jsonでアップデートURLとランタイムバージョンを設定します:
{
"expo": {
"runtimeVersion": "1.0.0",
"updates": {
"url": "https://your-server.com/api/expo-updates/manifest/"
}
}
}重要:runtimeVersionはアプリとサーバー間で一致する必要があります。ネイティブコードを変更したりExpo SDKをアップグレードしたりする場合は、ランタイムバージョンをインクリメントして新しいアップデートをパブリッシュしてください。
Tigrisを使ったストレージ#
Tigrisは、AWS S3よりも大幅に安価なS3互換オブジェクトストレージサービスで、グローバルエッジキャッシングが含まれています。
Djangoでの設定:
# settings.py
BUCKET_NAME = os.getenv("BUCKET_NAME")
AWS_ENDPOINT_URL_S3 = os.getenv("AWS_ENDPOINT_URL_S3")
AWS_ACCESS_KEY_ID = os.getenv("AWS_ACCESS_KEY_ID")
AWS_SECRET_ACCESS_KEY = os.getenv("AWS_SECRET_ACCESS_KEY")
AWS_REGION = os.getenv("AWS_REGION", "auto")S3クライアントの作成:
import boto3
def create_s3_client(endpoint_url, region, access_key, secret_key):
return boto3.client(
"s3",
endpoint_url=endpoint_url,
region_name=region,
aws_access_key_id=access_key,
aws_secret_access_key=secret_key,
)ファイルアップロードはCDN直接配信のためにpresigned URLを使用します:
presigned_url = s3_client.generate_presigned_url(
"get_object",
Params={"Bucket": bucket_name, "Key": asset.file_path},
ExpiresIn=3600, # 1 hour
)セキュリティに関する考慮事項#
認証#
マニフェストエンドポイントは設計上認証なしでアクセス可能です—モバイルアプリはユーザーがログインする前にアップデートが必要です。ただし、インポートエンドポイントには共有シークレットが必要です:
OTA_IMPORT_SECRET = os.getenv("OTA_IMPORT_SECRET")
# Constant-time comparison prevents timing attacks
if not hmac.compare_digest(token, secret):
return Response({"error": "Invalid token"}, status=401)アセットの整合性#
すべてのアセットはSHA-256ハッシュで検証されます。アセットが改ざんされるとハッシュが一致せず、アップデートは失敗します。
Presigned URL#
URLは1時間後に期限切れとなり、バンドルへの長期的な不正アクセスを防止します。
パフォーマンス最適化#
データベースインデックス#
(runtime_version, platform, is_active, -created_at)の複合インデックスにより、数千のアップデートがあってもマニフェストクエリが高速であることが保証されます:
class Meta:
indexes = [
models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
]並列アップロード#
パブリッシングスクリプトはThreadPoolExecutorを使用してアセットを同時にアップロードします:
with ThreadPoolExecutor(max_workers=10) as executor:
futures = {executor.submit(upload_asset, asset): asset for asset in assets}
for future in as_completed(futures):
# Track progress50個のアセットがある一般的なアップデートの場合、パブリッシュ時間が2分から15秒に短縮されます。
CDN配信#
Tigrisにはグローバルエッジキャッシングが含まれています。アセットはユーザーの近くのエッジロケーションに自動的に配信され、ダウンロード時間が短縮されます。
運用ワークフロー#
日常の開発#
# 1. Make code changes in mobile app
cd mobile-app && git commit -am "Fix bug"
# 2. Publish OTA update to local environment
yarn publish-update:ios
# 3. Test on device
# App automatically downloads and applies updateプロダクションデプロイメント#
# 1. Publish to production
yarn publish-update:prod:ios
# 2. Monitor
# Check Django admin for update records
# Verify assets in Tigris dashboardロールバック#
# Mark problematic update as inactive in Django admin
# or via management shell:
python manage.py shell
>>> from jobs.models import ExpoUpdate
>>> bad_update = ExpoUpdate.objects.get(id="uuid-here")
>>> bad_update.is_active = False
>>> bad_update.save()
# Clients will now receive the previous active updateコスト分析#
約500人のアクティブユーザーがいる私のCurtain Estimatorアプリの場合:
Tigrisストレージ:
- ストレージ:〜200 MB(過去のアップデート)= $0.02/月
- エグレス:〜50 GB/月(アップデートのダウンロード)= $1.00/月
- 合計:〜$1/月
Djangoホスティング(Fly.io):
- 既存のアプリホスティングに含まれる
- 追加コスト:$0
OTAインフラ総コスト:〜$1/月
同様の使用量でのEAS Updateの料金は年間$300-500です。自己ホスティングのアプローチは即座にコストを回収できます。
モニタリングとデバッグ#
ロギング#
ViewSetはすべてのマニフェストリクエストをログに記録します:
logger.info(f"Manifest request: platform={platform}, runtime={runtime_version}")Django Admin#
簡単な確認のためにDjango adminにモデルを登録します:
@admin.register(ExpoUpdate)
class ExpoUpdateAdmin(admin.ModelAdmin):
list_display = ["platform", "runtime_version", "is_active", "created_at"]
list_filter = ["platform", "is_active", "runtime_version"]
search_fields = ["description"]クライアント側のデバッグ#
アプリでアップデートログを有効にします:
import * as Updates from 'expo-updates';
Updates.checkForUpdateAsync().then(update => {
console.log('Update available:', update.isAvailable);
console.log('Manifest:', update.manifest);
});制限事項と注意点#
ランタイムバージョンのマッチング#
最も一般的な問題:クライアントは自身のランタイムバージョンに一致するアップデートのみをダウンロードします。アプリがランタイム1.0.0なのに1.0.1用にパブリッシュすると、アップデートは配信されません。
解決策:ランタイムバージョンをアプリのビルドと同期させ、ネイティブコードが変更された場合のみインクリメントしてください。
createdAtタイムスタンプ#
expo-updatesクライアントはマニフェストのcreatedAtタイムスタンプを組み込みバンドルのcommitTimeと比較します。アップデートはcreatedAtがより新しい場合のみ適用されます。
修正:ViewSetでcreatedAtをデータベースのタイムスタンプでオーバーライドします:
manifest_data["createdAt"] = update.created_at.strftime("%Y-%m-%dT%H:%M:%S.%fZ")ローカル開発で、OTAをパブリッシュした後にバイナリをビルドした場合は、より新しいタイムスタンプを確保するためにOTAを再パブリッシュしてください。
マニフェストのアセットkey値#
マニフェスト内の各アセットのkeyフィールドは、expo-updatesのキャッシュに使用されます。ランダムなUUIDや任意の文字列ではなく、決定論的なハッシュ(ファイル名のMD5など)でなければなりません。ランダムな値を使用すると、クライアントがアセットを正しくキャッシュまたは取得できず、最初の読み込み成功後にアップデートがサイレントに失敗する可能性があります。この問題を報告してくれた読者のRaphael Mutschlerに感謝します。彼はこの問題を発見するまで、アップデートがちょうど1回だけ動作していました。
expoClientのアプリ設定#
アプリでLinking、Constants、またはランタイムにアプリ設定を読み取るその他の機能を使用している場合、マニフェストのextra.expoClientフィールドにアプリ設定を含める必要があります。これがないと、アプリは最初は正常に起動しますが、閉じた後に再度開くとクラッシュしたり失敗したりする可能性があります。expo-updatesが組み込みマニフェストをOTAマニフェストに置き換えるため、expoClientがないとそれらのAPIが依存する設定にアクセスできなくなるためです。この問題もRaphael Mutschlerが発見してくれました。
アセットのクリーンアップ#
古いアップデートがTigrisに蓄積されます。現在、クリーンアップは手動です:
# Delete updates older than 30 days
from datetime import timedelta
from django.utils import timezone
cutoff = timezone.now() - timedelta(days=30)
old_updates = ExpoUpdate.objects.filter(created_at__lt=cutoff, is_active=False)
for update in old_updates:
# Delete assets from S3
for asset in update.assets.all():
s3_client.delete_object(Bucket=bucket_name, Key=asset.file_path)
# Delete DB records
update.delete()スケジュールタスクへの追加を検討してください。
今後の改善#
ロールアウト制御#
アップデートを段階的にリリースするためにrollout_percentageフィールドを追加します:
rollout_percentage = models.IntegerField(default=100)
# In the manifest view:
if update.rollout_percentage < 100:
# Hash user ID and check if they're in rollout group
user_hash = int(hashlib.sha256(user_id.encode()).hexdigest(), 16)
if (user_hash % 100) >= update.rollout_percentage:
return Response(status=204) # No updateマルチ環境サポート#
ステージングとプロダクションで異なるアップデートを提供するためにenvironmentフィールドを追加します:
environment = models.CharField(max_length=20, default="production")
# Client sends environment in custom header
environment = request.META.get("HTTP_X_UPDATE_ENVIRONMENT", "production")
update = ExpoUpdate.objects.filter(environment=environment, ...).first()アナリティクス#
ダウンロードメトリクスを追跡します:
class ExpoUpdateDownload(models.Model):
update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE)
user_id = models.CharField(max_length=255, null=True)
platform = models.CharField(max_length=10)
downloaded_at = models.DateTimeField(auto_now_add=True)まとめ#
DjangoとS3互換ストレージを使った自己ホスト型Expo OTAアップデートは、思ったよりシンプルです。全体で必要なのは:
- 約150行のDjangoモデルとビュー
- 約200行のパブリッシングスクリプト
- 約$1/月のインフラコスト
ここで紹介したコード例は、私のプロダクションCurtain Estimatorアプリのものです。構築するものに合わせて活用してください。読者のRaphael Mutschlerがすぐに使えるスタンドアロン実装をexpo-ota-serverで公開していますので、参考にしてください。
仕様の詳細はExpo Updates Protocol Specificationをご覧ください。
完全なスクリプト#
publish-ota-update.sh#
#!/bin/bash
# Publish OTA Update Script
#
# Usage:
# ./scripts/publish-ota-update.sh # Both platforms (LOCAL)
# ./scripts/publish-ota-update.sh ios # iOS only (LOCAL)
# ./scripts/publish-ota-update.sh ios --production # iOS to PRODUCTION
# ./scripts/publish-ota-update.sh --dry-run # Test without uploading
# ./scripts/publish-ota-update.sh ios --description "Bug fixes"
set -e
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
RED='\033[0;31m'
NC='\033[0m'
# Parse arguments
PLATFORM="all"
PRODUCTION=false
DRY_RUN=false
DESCRIPTION=""
while [[ $# -gt 0 ]]; do
case $1 in
ios|android|all) PLATFORM="$1"; shift ;;
--production|--prod) PRODUCTION=true; shift ;;
--dry-run) DRY_RUN=true; shift ;;
--description) DESCRIPTION="$2"; shift 2 ;;
-h|--help)
echo "Usage: $0 [ios|android|all] [--production] [--dry-run] [--description \"msg\"]"
exit 0 ;;
*) echo -e "${RED}Unknown: $1${NC}"; exit 1 ;;
esac
done
# Auto-detect project root (support running from mobile-app/ via yarn)
if [ -d "mobile-app" ]; then
: # already at project root
elif [ -d "../mobile-app" ]; then
cd ..
else
echo -e "${RED}Error: Run from project root or mobile-app/${NC}" && exit 1
fi
docker info > /dev/null 2>&1 || { echo -e "${RED}Error: Docker not running${NC}"; exit 1; }
# Log file — verbose output goes here, terminal gets summary only
LOG_FILE="ota-publish-$(date +%Y%m%d-%H%M%S).log"
echo -e "${BLUE}═══ Expo OTA Publisher ═══${NC}"
echo -e "Platform: ${PLATFORM} Production: ${PRODUCTION} Log: ${LOG_FILE}"
echo ""
# ── Step 1: Export with production env vars ──
echo -e "${YELLOW}Step 1: Exporting mobile app...${NC}"
cd mobile-app
# Load production env vars from eas.json (adapt these to your app's env vars)
if [ -f "eas.json" ] && command -v jq &> /dev/null; then
for key in $(jq -r '.build.production.env // {} | keys[]' eas.json); do
export "$key"="$(jq -r ".build.production.env.$key" eas.json)"
done
fi
OTA_EXPORT_DIR="dist-ota"
if [ "$PLATFORM" = "all" ]; then
npx expo export --platform ios --output-dir "$OTA_EXPORT_DIR" >> "../$LOG_FILE" 2>&1
npx expo export --platform android --output-dir "$OTA_EXPORT_DIR" >> "../$LOG_FILE" 2>&1
else
npx expo export --platform "$PLATFORM" --output-dir "$OTA_EXPORT_DIR" >> "../$LOG_FILE" 2>&1
fi
cd ..
echo -e "${GREEN}✓ Export complete${NC}"
# ── Step 2: Upload to Tigris + create DB records ──
echo -e "${YELLOW}Step 2: Publishing to Tigris...${NC}"
CMD_ARGS="--platform $PLATFORM --export-dir mobile-app/$OTA_EXPORT_DIR"
[ "$DRY_RUN" = true ] && CMD_ARGS="$CMD_ARGS --dry-run"
[ -n "$DESCRIPTION" ] && CMD_ARGS="$CMD_ARGS --description \"$DESCRIPTION\""
[ "$PRODUCTION" = true ] && CMD_ARGS="$CMD_ARGS --production-sync"
PUBLISH_OUTPUT=$(eval docker compose exec -T django python manage.py publish_expo_update $CMD_ARGS 2>&1)
echo "$PUBLISH_OUTPUT" >> "$LOG_FILE"
# Print key lines to terminal
echo "$PUBLISH_OUTPUT" | grep -E '✓ Published:|Deactivated|OTA_S3_KEY=|DRY RUN|ERROR|Failed' || true
# ── Step 3 (production only): Sync via API endpoint ──
if [ "$PRODUCTION" = true ] && [ "$DRY_RUN" = false ]; then
echo -e "${YELLOW}Step 3: Syncing to production...${NC}"
# Extract S3 key(s) from management command output
S3_KEYS=$(echo "$PUBLISH_OUTPUT" | grep -o 'OTA_S3_KEY=[^ ]*' | sed 's/OTA_S3_KEY=//')
[ -z "$S3_KEYS" ] && echo -e "${RED}Error: No OTA_S3_KEY found in publish output${NC}" && exit 1
# Read OTA_IMPORT_SECRET from .env
if [ -f ".env" ]; then
OTA_IMPORT_SECRET=$(grep -E '^OTA_IMPORT_SECRET=' .env | sed 's/^OTA_IMPORT_SECRET=//')
fi
[ -z "$OTA_IMPORT_SECRET" ] && echo -e "${RED}Error: OTA_IMPORT_SECRET not found in .env${NC}" && exit 1
PROD_URL="https://your-app.fly.dev/api/expo-updates/import-update/"
for S3_KEY in $S3_KEYS; do
RESPONSE=$(curl -s -w "\n%{http_code}" -X POST "$PROD_URL" \
-H "Authorization: Bearer $OTA_IMPORT_SECRET" \
-H "Content-Type: application/json" \
-d "{\"s3_key\": \"$S3_KEY\"}")
HTTP_CODE=$(echo "$RESPONSE" | tail -1)
BODY=$(echo "$RESPONSE" | sed '$d')
echo "$BODY" >> "$LOG_FILE"
if [ "$HTTP_CODE" = "200" ]; then
UPDATE_ID=$(echo "$BODY" | python3 -c "import sys,json; print(json.load(sys.stdin)['update_id'])" 2>/dev/null || echo "unknown")
PLAT=$(echo "$BODY" | python3 -c "import sys,json; print(json.load(sys.stdin)['platform'])" 2>/dev/null || echo "unknown")
NOTIF_COUNT=$(echo "$BODY" | python3 -c "import sys,json; print(json.load(sys.stdin).get('notifications_sent', 0))" 2>/dev/null || echo "0")
echo -e "${GREEN}✓ ${PLAT}: ${UPDATE_ID}${NC}"
echo -e "${GREEN}✓ Sent ${NOTIF_COUNT} push notification(s) to production users${NC}"
else
echo -e "${RED}Error: HTTP $HTTP_CODE${NC}"
echo "$BODY"
exit 1
fi
done
fi
echo ""
echo -e "${GREEN}═══ ✓ Done ═══${NC}"
echo -e "Full log: ${LOG_FILE}"sync-ota-to-prod.sh#
#!/bin/bash
# Sync OTA Update to Production Database
# This script copies an OTA update record from local to production database
# The bundles are already in Tigris (shared between local and production)
set -e
# Colors
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
# Get the update ID from arguments or use the latest
UPDATE_ID="$1"
if [ -z "$UPDATE_ID" ]; then
echo -e "${YELLOW}No update ID provided, using latest iOS update...${NC}"
UPDATE_ID=$(docker compose exec -T django python manage.py shell -c "
from jobs.models import ExpoUpdate
update = ExpoUpdate.objects.filter(platform='ios').order_by('-created_at').first()
print(update.id if update else '')
" | tail -1 | tr -d '\r\n')
fi
echo -e "${BLUE}Syncing OTA Update to Production${NC}"
echo -e "${BLUE}Update ID: $UPDATE_ID${NC}"
echo ""
# Export the update data from local database
echo -e "${YELLOW}Step 1/2: Exporting from local database...${NC}"
docker compose exec -T django python manage.py shell -c "
import json
from jobs.models import ExpoUpdate, ExpoUpdateAsset
try:
update = ExpoUpdate.objects.get(id='$UPDATE_ID')
except ExpoUpdate.DoesNotExist:
print('ERROR: Update not found')
exit(1)
# Export update
print(json.dumps({
'id': str(update.id),
'runtime_version': update.runtime_version,
'platform': update.platform,
'is_active': update.is_active,
'manifest_data': update.manifest_data,
'description': update.description,
'assets': [
{
'id': str(asset.id),
'hash': asset.hash,
'key': asset.key,
'content_type': asset.content_type,
'file_extension': asset.file_extension,
'file_path': asset.file_path,
'file_size': asset.file_size,
}
for asset in update.assets.all()
]
}))
" > /tmp/ota_sync_$UPDATE_ID.json
# Check if export succeeded
if [ ! -s /tmp/ota_sync_$UPDATE_ID.json ]; then
echo -e "${RED}Failed to export update${NC}"
exit 1
fi
echo -e "${GREEN}✓ Exported update data${NC}"
echo ""
# Import to production database
echo -e "${YELLOW}Step 2/2: Importing to production database...${NC}"
# Create Python script for import
cat > /tmp/ota_import.py << 'EOFPY'
import json
from jobs.models import ExpoUpdate, ExpoUpdateAsset
with open('/tmp/ota_data.json', 'r') as f:
data = json.load(f)
# Create or update the ExpoUpdate record
update, created = ExpoUpdate.objects.update_or_create(
id=data['id'],
defaults={
'runtime_version': data['runtime_version'],
'platform': data['platform'],
'is_active': data['is_active'],
'manifest_data': data['manifest_data'],
'description': data['description'],
}
)
print(f"Update: {'created' if created else 'updated'}")
print(f" ID: {update.id}")
print(f" Platform: {update.platform}")
print(f" Runtime: {update.runtime_version}")
print(f" Description: {update.description}")
# Create assets
assets_created = 0
for asset_data in data['assets']:
_, created = ExpoUpdateAsset.objects.update_or_create(
id=asset_data['id'],
defaults={
'update': update,
'hash': asset_data['hash'],
'key': asset_data['key'],
'content_type': asset_data['content_type'],
'file_extension': asset_data['file_extension'],
'file_path': asset_data['file_path'],
'file_size': asset_data['file_size'],
}
)
if created:
assets_created += 1
print(f"Assets: {assets_created} created, {len(data['assets']) - assets_created} updated")
print(f"✓ OTA update successfully synced to production!")
EOFPY
# Copy JSON to temp location and import
flyctl ssh console -C "cat > /tmp/ota_data.json" < /tmp/ota_sync_$UPDATE_ID.json
flyctl ssh console -C "cat > /tmp/ota_import.py" < /tmp/ota_import.py
flyctl ssh console -C "python manage.py shell < /tmp/ota_import.py"
# Cleanup
rm /tmp/ota_sync_$UPDATE_ID.json /tmp/ota_import.py
echo ""
echo -e "${GREEN}╔════════════════════════════════════════════════════════════╗${NC}"
echo -e "${GREEN}║ ✓ OTA Update Synced to Production! ║${NC}"
echo -e "${GREEN}╚════════════════════════════════════════════════════════════╝${NC}"
echo ""
# Verify
echo -e "${BLUE}Verifying production...${NC}"
flyctl ssh console -C "python manage.py shell -c \"
from jobs.models import ExpoUpdate
count = ExpoUpdate.objects.count()
latest = ExpoUpdate.objects.order_by('-created_at').first()
print(f'Total OTA updates: {count}')
if latest:
print(f'Latest: {latest.platform} - {latest.description}')
\""
