izone is a Django blog that also carries docs, comments and scheduled jobs

A blog that also serves as a documentation site, with a Django admin behind it

izone is described as a personal blog system built on the Django framework, and the project description adds that it can also be used as a documentation management website, with comments, scheduled tasks and other features built in, and an interface that is simple without being plain.

The live site is tendcode.com, and the topics on the repository list blog, bootstrap, django, docker and python, so the search intent behind the project is a self-hosted personal site rather than a publishing platform.

The Django admin is the first thing the feature list mentions, described as convenient for managing articles, users and other dynamic content. That is the practical core of the project. A blog built on Django with the admin enabled gives you an editing interface, a user model and a content workflow for free, and the rest of the feature set is built on top of that rather than replacing it.

The content model has three levels, Subject to Topic to Article, which is what makes the same system work as a documentation site. A blog only needs categories and tags; a documentation site needs a hierarchy where a subject groups topics and an article sits under a topic. The screenshot list in the README includes a topic page that groups articles by category, which is that hierarchy made visible.

The rest of the feature list is broad for a personal blog. Full-text search with MySQL FULLTEXT and n-gram Chinese tokenisation, querying live data directly. A comment system with two-level replies, weibo-style emoji and Markdown, plus comment notifications. User authentication with Django's own system plus OAuth login through Weibo and GitHub. View counting that filters crawler user agents, de-duplicates by visitor over 30 minutes, and takes a daily snapshot. Friend link management with online applications and scheduled automatic link checking, with a concurrency limit on outbound requests. RSS, a sitemap, and Baidu SEO push. A RESTful API that is conditionally enabled, built on DRF's DefaultRouter, where list endpoints do not return the body content. Online tools that are conditionally enabled, service monitoring, a navigation site, flowcharts and script tool sharing. A responsive design for PC, iPad and phone, with a dark theme.

It is a personal site that has grown into a small platform, and the documentation index in the repository shows the project is managed as a product rather than a weekend project.

The stack is pinned to Django 2.2 and Python 3.9, on purpose

The technology stack table in the README is explicit, and the versions are old enough that an adopter has to make a decision about them.

The backend is Django 2.2 with Python 3.9. The database is MySQL with utf8mb4. Redis handles cache and message queue. Celery 4.4 handles asynchronous tasks, with the Worker and Beat merged into a single process. The search engine is MySQL FULLTEXT with n-gram Chinese tokenisation. The frontend is Bootstrap 4 with jQuery. Containerisation is Docker with Gunicorn and Supervisord.

The requirements.txt confirms the pins precisely: Django 2.2.28, celery 4.4.2, gunicorn 19.9.0, requests 2.22.0, redis 3.3.8, urllib3 1.25.3, djangorestframework 3.11.2, and a set of packages from the same era, django-allauth 0.42.0 and django-crispy-forms 1.7.2 among them. The Dockerfile is built FROM python:3.9, which confirms the runtime.

There is also jieba 0.39 in the requirements, the Chinese word segmentation library, and cairosvg at the end of the list for rendering SVG.

For a personal site that already exists, this stack is a feature, because the deployment is reproducible and the project is not chasing a moving target. For a new commercial product in 2026, the same pins are a liability, and the honest reading is that adopting izone means adopting Django 2.2, which no longer receives upstream security fixes.

The search choice is the one that will surprise you if you do not read it. The changelog line dated 2026-09-05 says the search was switched to MySQL FULLTEXT, removing haystack and Whoosh. So full-text search is now a database feature rather than an application-level one, querying live data directly instead of maintaining a separate index. That removes a component and a synchronisation problem, and it moves the requirement onto the database server, which has to be configured for n-gram tokenisation to handle Chinese.

Docker deployment needs MySQL and Redis already running

The quick start offers a Docker path and a local development path, and the Docker path makes an assumption that is stated in a comment.

The image build is:

# 构建镜像
docker build -t hopetree/izone:lts .

There is also a slim variant, with the build arguments for a domestic mirror of the package index and the Debian package mirror:

# slim 镜像（国内构建）
docker build --build-arg pip_index_url=http://mirrors.aliyun.com/pypi/simple/ \
             --build-arg pip_trusted_host=mirrors.aliyun.com \
             --build-arg debian_host=mirrors.ustc.edu.cn \
             -f Dockerfile-slim -t hopetree/izone:lts .

The run command is where the dependency becomes clear, since the comment says MySQL and Redis need to be started in advance:

# 运行（需要预先启动 MySQL 和 Redis）
docker run -d \
  -e IZONE_MYSQL_HOST=mysql_host \
  -e IZONE_MYSQL_PASSWORD=your_password \
  -e IZONE_REDIS_HOST=redis_host \
  -p 8000:8000 \
  hopetree/izone:lts

So the container is the application, not the whole stack. There is no MySQL or Redis in the compose file, and the two hosts are passed as environment variables, which means you decide where they live.

Two details in the Dockerfile are worth noting. The image installs libcairo2 and fonts-noto-cjk, which is what lets the Chinese text render correctly rather than as boxes, and it copies the Asia/Shanghai zoneinfo into /etc/localtime, pinning the container's timezone. The Dockerfile also stamps the image build time into the site's update time by rewriting a variable in the base template, which is a small trick that makes a container rebuild visible on the site.

The entrypoint is entrypoint.sh and the command is supervisord -n -c supervisord.conf, so supervisord is what runs the application processes inside the container.

Local development is a venv, a migration and a superuser

The local development path is the standard Django sequence with one addition, and it is short enough to read in full:

# 安装依赖
python -m venv env
source env/bin/activate
pip install -r requirements.txt

# 数据库迁移
python manage.py migrate

# 创建管理员
python manage.py createsuperuser

# 启动开发服务器
python manage.py runserver

# 启动 Celery（可选，异步任务需要；Worker 与 Beat 单进程）
celery -A izone worker -l info -B --pool=solo

The Celery invocation is worth examining. It is a single process with -B, which is the embedded Beat scheduler, and --pool=solo, which runs tasks in the main process rather than forking. The README's changelog line for 2026-09-05 records the same change, that the Celery Worker and Beat were merged into a single process.

That merge is the kind of decision that trades throughput for simplicity. A single Celery process with an embedded scheduler is much easier to run in a container and in a small server, and for a personal blog with a handful of scheduled tasks it is the right trade. A site with a heavy scheduled workload would want them separated, since the scheduler and the workers compete for the same process.

The environment variable table lists the key settings. IZONE_DEBUG controls debug mode and defaults to True, which is the one default worth changing before you expose the site. IZONE_MYSQL_HOST defaults to 127.0.0.1 and IZONE_MYSQL_PASSWORD defaults to python. IZONE_REDIS_HOST defaults to 127.0.0.1. IZONE_TOOL_FLAG enables the online tools and defaults to True, and IZONE_API_FLAG enables the REST API and also defaults to True. The complete list is in the architecture design document.

That both feature flags defaulting to on is worth a moment's thought. The online tools and the REST API are the two parts of the site that expand its attack surface, and the default configuration turns both on.

Redis does the caching and the view de-duplication

The cache list is specific enough to be useful, and it covers a set of things a personal site usually gets wrong.

The README lists Redis caching for article rendering, RSS body content, site configuration, sidebar statistics and unread counts, plus Celery for scheduled task scheduling. Those five cached items are the ones that change on a timer or change often, and caching them keeps the page render off the database for the paths that visitors hit most.

View counting gets its own mechanism, and it is the more interesting one. The feature list says views are counted with crawler user agent filtering, de-duplication per visitor over 30 minutes, and a daily snapshot. The changelog line for 2026-09-11 records the change to de-duplicate by visitor over 30 minutes in Redis, so the 30-minute window is implemented as a Redis key rather than a database column.

The crawler filtering matters as much as the de-duplication. A personal blog is crawled by search engines and monitoring services, and without filtering the view counts are mostly noise. The requirements list includes ua-parser, user-agent and user-agents, which are the libraries for parsing a user agent string, so the filtering is a real parse rather than a substring check.

The friend link feature is the other place with a stated constraint. The feature list says online application, scheduled automatic link checking, with a concurrency limit on outbound requests, and the changelog line for the same date mentions the concurrency limit. That is a defensive measure against a common failure mode, where a blog with hundreds of outbound friend links triggers rate limits or a slow partner site stalls the whole scheduled run.

The comment system has its own supporting pieces: bleach for sanitising HTML, Markdown 3.4.3 and markdown-checklist for rendering, django-allauth 0.42.0 for the authentication flows, and python3-openid and oauthlib for the OAuth side.

The project is documented like a product, with an AGENTS.md and a code review report

The documentation index in the README is the strongest signal about how this project is run.

There is a product requirements specification document covering the feature list and the non-functional requirements, an architecture design document covering technology selection, module division and deployment architecture, a database design document with entity definitions, relationship explanations and design decisions, an API interface document listing the JSON API endpoints per application, a code review report, and AGENTS.md described as the project working guide with an architecture overview, commit conventions and build constraints.

A code review report and an AGENTS.md in the same repository is a combination that says a lot about the workflow. The code review report is described as a code review and issue tracking document, which means the review findings are tracked as artefacts rather than living in a discussion. The AGENTS.md, with commit conventions and build constraints, is aimed at automated coding assistants working in the repository.

The project structure in the README matches the Django application layout, with an izone/ directory for the project configuration covering settings, urls and wsgi, and an apps/ directory holding every Django application: blog as the core, oauth for the custom user model and OAuth authentication, comment for comments and notifications, easytask for the Celery asynchronous tasks, api for the REST API, tool for the online tools, monitor for service monitoring, and others including webstack, resume, flow, portinfo and rsshub. There are also templates/ for shared templates, utils/ for shared utilities such as Markdown extensions, docs/design/ for the design documents, the two Dockerfiles, and manage.py.

The licence is MIT, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. The only tagged release is lts from 2024-02-28, and the repository is not archived with the last push on 2026-09-30, so the project is maintained in the repository without cutting new tags.

Editorial conclusion

Adopt izone if you want a ready-made Django site for a personal blog that doubles as a documentation site, and you are content to run Django 2.2 on Python 3.9. Do not adopt it for a new commercial product without reading the requirements list first, because the pinned versions of Django, Celery, requests and gunicorn are years old. Before you deploy, remember that MySQL and Redis have to be running first, that the debug mode default is True, and that the full-text search relies on MySQL FULLTEXT with n-gram tokenisation, which means your database server has to be configured for Chinese tokenisation.

Frequently asked questions

Official sources

1. Hopetree/izone on GitHub
2. License: MIT
3. Project website
4. README
5. Releases