[CRITICAL] django-cf D1 backend runs tests against production database, causing data loss

[Phat-pham99]

Summary

When running Django tests with django-cf's D1 backend (django_cf.d1_api or django_cf.db.backends.d1), Django's test runner does not create a separate test database. Instead, it connects directly to the production D1 database and wipes all data during test setup/teardown.

Impact

This is a critical data-loss bug. My production Cloudflare D1 was wiped out. But luckily the Cloudflare D1 has Time travel enabled by default. Therefore I was able to restore the data.

Steps to Reproduce

1. Configure Django with the D1 API backend:

DATABASES = {
    'default': {
        'ENGINE': 'django_cf.d1_api',  # or django_cf.db.backends.d1
        'CLOUDFLARE_DATABASE_ID': '...',
        'CLOUDFLARE_ACCOUNT_ID': '...',
        'CLOUDFLARE_TOKEN': '...',
    }
}

2. Have existing data in the D1 database (e.g., tables from previous migrations).
3. Run python manage.py test.

Expected Behavior

Django's test runner should either:

• Create a separate, isolated test database on D1, or
• Raise a clear error/warning that testing against D1 is unsafe, or
• Use an in-memory SQLite database for tests by default.

Actual Behavior

The test runner executes migrations, flushes data, and runs tests directly against the configured D1 database. Since D1 does not support database-level cloning or rollback (transactions are disabled), all production data is permanently lost.

Root Cause Analysis

Looking at the D1 backend implementation:

• In django_cf/db/backends/d1/base.py, DatabaseWrapper inherits from CFDatabaseWrapper.
• CFDatabaseCreation inherits from Django's SQLiteDatabaseCreation.
• The backend does not override the test database creation methods (_create_test_db, _destroy_test_db, etc.) to account for D1's serverless nature.
• Unlike SQLite (which creates a local file), D1 is a remote HTTP API. Django cannot simply create a "test_" prefixed database file.
• The supports_transactions = False flag is set, but Django still attempts to flush and migrate the "test" schema, which in practice targets the same database.

Environment

• django-cf version: >=0.1.1 (tested on 0.1.1, likely affects 0.2.x as well)
• Django version: >=5.0
• Python version: >=3.10

Suggested Fix

Short-term (Immediate)

Override DatabaseCreation in the D1 backend to raise a ImproperlyConfigured exception if manage.py test is detected, with a message like:

"Running Django tests against Cloudflare D1 is not supported because D1 does not support isolated test databases. Please configure a separate test database (e.g., SQLite or a dedicated D1 database) using the TEST setting."

Long-term

Implement proper test database isolation, such as:

1. SQLite fallback for tests: If TEST configuration is not provided, default to an in-memory SQLite database for tests.
2. D1 test database creation: Allow users to specify a separate CLOUDFLARE_DATABASE_ID under DATABASES['default']['TEST'], and create/destroy that via the D1 API during test runs.

Example safe configuration pattern:

DATABASES = {
    'default': {
        'ENGINE': 'django_cf.db.backends.d1',
        'CLOUDFLARE_DATABASE_ID': os.getenv('CLOUDFLARE_DATABASE_ID'),
        'TEST': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': ':memory:',
        },
    }
}

Additional Context

This bug has already caused complete data loss in a production D1 database. I discovered this after running python manage.py test and finding all tables and data erased. Because D1 does not support transactions or point-in-time recovery, the data is unrecoverable.

Please prioritize this issue, as it poses a serious risk to anyone using django-cf with D1 in production.

[Phat-pham99]

My bad, I created issue on wrong repo

[dom96]

django-cf is now in this repo, so this issue should be reported here.

@ryanking13 @G4brym should we add a note to https://github.com/G4brym/django-cf that it no longer lives there (or maybe even archive that repo?)

[G4brym]

Agreed, i just pushed a banner to the top of readme.md and arquived the old repo

[Phat-pham99]

Thanks guys

[ryanking13]

Could you please elaborate on your test environment? I don't quite understand how you are running django unittests against d1 database.

D1 database doesn't work unless you are under the workers environment so running python manage.py test in the host environment will not work. Also, if you are meaning that you are running things inside workers, running tests in local environment (pywrangler dev) would use the local binding which is not actually a prod DB.

[Phat-pham99]

Could you please elaborate on your test environment? I don't quite understand how you are running django unittests against d1 database.

D1 database doesn't work unless you are under the workers environment so running python manage.py test in the host environment will not work. Also, if you are meaning that you are running things inside workers, running tests in local environment (pywrangler dev) would use the local binding which is not actually a prod DB.

Hi @ryanking13, thank you for your response. Let me elaborate on this.

I was doing test on local machine, not a CF worker. I connected to CF D1 directly without wrangler.

My first thought is that Cloudflare D1 is basically a remote, managed SQLite database. Which is backed by the fact that the base_engine is inherited from django.db.backends.sqlite3 classes
That's why I expected the django-cf will spinup a local SQLite database for testing purpose and teardown afterward.
But what happened is that the library initiated a connection using the configed production D1 credential during the tests and migrated directly to it. It really caused data loss on my production CF D1.

[Phat-pham99]

Here is the project I was working on when I found this issue:

https://github.com/Phat-pham99/Phat_Django_Badass

[ryanking13]

Here is the project I was working on when I found this issue:

https://github.com/Phat-pham99/Phat_Django_Badass

I cannot find any usage of django-cf D1 backend in the main branch of that repository. Is it in a different branch? Also, django-cf should not use any CLOUDFLARE_TOKEN or CLOUDFLARE_ACCOUNT_ID env vars as it works using bindings not Cloudflare REST APIs

[Phat-pham99]

Here is the project I was working on when I found this issue:
https://github.com/Phat-pham99/Phat_Django_Badass

I cannot find any usage of django-cf D1 backend in the main branch of that repository. Is it in a different branch? Also, django-cf should not use any CLOUDFLARE_TOKEN or CLOUDFLARE_ACCOUNT_ID env vars as it works using bindings not Cloudflare REST APIs

The database backend config is in here https://github.com/Phat-pham99/Phat_Django_Badass/blob/main/settings/databases.py#L7-L15
I configured ENGINE as django_cf.d1_api

Furthermore, Cloudflare's own REST API documentation https://developers.cloudflare.com/api/resources/d1 shows direct API access is still one of supported integration methods. The django-cf library implements a Django backend for this exact use case. Direct API access is not an edge case or unsupported workflow — it is the documented way to integrate D1 outside of Workers/Wrangler.

I meant, I have been using this REST connection for my projects ever since and it works.

[ryanking13]

I see. django_cf.d1_api backend is removed from v0.2 and not supported at this point (@G4brym could you please confirm?).

django-cf is currently focused on running django inside Python workers, and it does not support D1 backend in native environments.

[Phat-pham99]

Thank you for the confirmation, I'm still using the old version as 0.1.1
My bad 😅
I think will re-implement the Cloudflare D1 Restful connection logic on my current project to make sure it will be stable in the future. It's quite simple actually.
Yupe, we are all good now. Thanks guys @ryanking13 and @G4brym

[ryanking13]

No problem! Closing as resolved, but please let us know any other issues you have using django-cf.