Blog entry
Deploy on render
This guide assumes you just finished the Wagtail tutorial, your .gitignore is set up, and you have not done anything related to deployment yet. It covers everything from first install to a live site, including Cloudinary for media storage.
Your current project structure
mysite/
├── .venv/
├── mysite/
│ ├── base/
│ ├── blog/
│ ├── home/
│ ├── media/
│ ├── mysite/
│ │ ├── settings/
│ │ │ ├── __init__.py
│ │ │ ├── base.py ← shared settings (INSTALLED_APPS, etc.)
│ │ │ ├── dev.py ← local dev (SQLite, DEBUG=True, SECRET_KEY)
│ │ │ └── production.py ← production (we'll edit this)
│ │ ├── static/
│ │ ├── templates/
│ │ ├── __init__.py
│ │ ├── urls.py
│ │ └── wsgi.py
│ ├── portfolio/
│ ├── search/
│ ├── .dockerignore
│ ├── .gitignore
│ ├── db.sqlite3
│ ├── Dockerfile
│ ├── manage.py
│ ├── requirements.txt
│ └── README.mdWhy Cloudinary?
Render's web services have an ephemeral filesystem — any files written to disk (like uploaded images) are lost on every deploy or restart. So if you upload images through Wagtail's admin, they'd disappear next time Render rebuilds your app.
Cloudinary solves this by storing your media files (images, documents) on their cloud servers instead of on Render's disk. Your images are served via Cloudinary's CDN, which is also faster for your visitors.
The good news: you don't need to change any of your models, templates, or blocks. Your ForeignKey('wagtailimages.Image', ...), ImageBlock(), FieldPanel('image'), and {% image %} template tags all stay exactly the same. Cloudinary works at the storage layer — it just changes where the file bytes get saved.