Build a Python API on Cloudflare

Deploy a Python API on Cloudflare Workers that reads from a D1 database.

Introduction

30 Second Summary

Code that works on your laptop is hard to share with anyone else. The moment you add stored data, getting it online can feel like a second project.

In this project, you will build a deployed Python API on Cloudflare Workers. One route returns JSON while the other reads rows from a D1 database.

What You'll Build

At your live workers.dev URL, one route returns a clean JSON response while the other pulls rows from your database.

By the end of this project, you'll have:

  • A local development loop that shows each Python Worker response before deployment.
  • A database-backed JSON route that returns stored rows from D1.
  • A public deployment with live request logs that prove each call reached your Worker.
  • Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You'll need a free Cloudflare account plus basic Python experience. Node must already be installed locally. The first step installs wrangler for you.

Before We Start

Your finished API runs on Cloudflare Workers. Building it starts with a local toolchain that can create the project.

In this step, you'll prepare a Cloudflare account. That account becomes the home for your deployed Worker later.

Node.js supplies the tooling that manages the project. Python supplies the runtime for your API.

In this step, get ready to:
  • Create a Cloudflare account for your Worker.
  • Install Node.js with npm.
  • Install Python and verify each tool from a terminal.
Create your Cloudflare account

A Cloudflare account connects your local work to the platform that hosts the finished API. This project stays on Cloudflare's free plan.

You do not need to add payment details. Your password stays inside Cloudflare's sign-up form.

  • Open the official Cloudflare sign-up page in your browser.
  • Enter your email address in the Email field.
  • Enter a unique password in the Password field.
  • Select Create Account.
  • Open the verification email from Cloudflare.
  • Use the verification link to confirm your email address.

Good start. Your Cloudflare account is now ready to receive the Worker you deploy later.

Prepare Node.js and npm

Node.js runs the project tooling on your computer. The official Node.js installer includes npm.

  • Press Cmd+Space on macOS or the Windows key on Windows to open system search.
  • Type Terminal on macOS or PowerShell on Windows into the search bar.
  • Press Enter to open the terminal.
  • Check whether Node.js and npm are available by running these commands:
node --version
npm --version

What do these commands check?

  • The node --version command displays the installed Node.js version.
  • The npm --version command displays the installed package manager version.

✔️ I see two version numbers

Node.js and npm are ready. Keep this terminal open for the Python check.

ⓧ A command is not found

Installing the Long Term Support release gives you Node.js and npm in one installer.

  • Open the official Node.js download page in your browser.
  • Download the Long Term Support installer for your operating system.
  • Complete the downloaded installer with its default options.
  • Approve the operating system permission request if one appears.
  • Close the terminal from earlier.
  • Reopen the terminal through system search.
  • Confirm the installation by running these commands:
node --version
npm --version

What should you see?

Each command prints a version number. Those results confirm that both tools are available from your terminal.

Still missing a command?

  • Restart your computer to reload the terminal's command paths.
  • Use the installer for your operating system from the official Node.js download page.
  • Help me make Node.js and npm available in my terminal.
Prepare Python and verify your tools

Python runs the API code you build in the next step. Its version command differs between macOS and Windows.

  • Check whether Python is available by choosing the command for your operating system below:

macOS

  • Check your Python installation by running this command in the Terminal from earlier:
python3 --version

What does this command check?

The python3 --version command displays the Python 3 version available to your terminal.

Windows

  • Check your Python installation by running this command in PowerShell:
py --version

What does this command check?

The py --version command displays the Python version selected by the Windows launcher.

  • Choose the outcome that matches your terminal result.

✔️ I see a Python version

Python is ready. Your terminal can now reach every prerequisite for the Worker project.

ⓧ The command is not found

Install the current Python 3 release from the official download page for your operating system.

macOS

  • Open the official Python releases for macOS page in your browser.
  • Download the current Python 3 macOS installer.
  • Complete the downloaded installer with its default options.
  • Approve the macOS permission request if one appears.
  • Close the Terminal from earlier.
  • Reopen Terminal through system search.
  • Confirm the installation by running this command:
python3 --version
What should you see?

The command prints a Python 3 version. This confirms that the installer added Python to your terminal's command path.

Windows

  • Open the official Python releases for Windows page in your browser.
  • Download the current Python 3 Windows installer.
  • Complete the downloaded installer with its default options.
  • Approve the Windows permission request if one appears.
  • Close PowerShell.
  • Reopen PowerShell through system search.
  • Confirm the installation by running this command:
py --version
What should you see?

The command prints a Python version. This confirms that the Windows launcher can reach the installed runtime.

Still unable to run Python?

  • Restart your computer to reload the command paths created by the installer.
  • Run the official installer again if the command remains unavailable.
  • Help me make Python available in my terminal.

Before the final check, what three version results do you expect your terminal to return?

macOS

  • Verify your complete toolchain by running these commands in Terminal:
node --version
npm --version
python3 --version

What does this final check prove?

The three commands confirm that Node.js, npm, and Python are available from the same terminal session.

Windows

  • Verify your complete toolchain by running these commands in PowerShell:
node --version
npm --version
py --version

What does this final check prove?

The three commands confirm that Node.js, npm, and Python are available from the same PowerShell session.

You should see three version numbers with no missing commands. That's the setup complete: your local computer is ready to create a Python Worker.

Missing one of the three results?

  • Return to the matching installation outcome above for the missing tool.
  • Reopen your terminal after completing the installer.
  • Help me fix my final toolchain check.

Your Cloudflare account and local toolchain are ready. Next up, you'll create your Python Worker and run its first response locally.

Create and Run Your Python Worker

Your database-backed API needs a working request path before you add routes or data. A local Python Worker gives you that first proof.

Wrangler creates the project structure for your API. It also runs the Worker on your computer so you can test every change before deployment.

In this step, get ready to:
  • Create the python-d1-api project from the Python Worker template.
  • Authenticate Wrangler with your Cloudflare account.
  • Run the template locally and confirm its response.
Create the Python Worker project

The C3 project generator creates a Python entry point alongside its Wrangler configuration. It also installs Wrangler inside the new project.

  • Approve the one-time create-cloudflare package installation if npm asks for permission.
  • Create python-d1-api on your Desktop by running these commands:
cd ~/Desktop
npm create cloudflare@latest -- python-d1-api --category=hello-world --type=hello-world --lang=python --no-deploy --no-git

What does this command create?

  • The hello-world options select the starter Worker template.
  • The --lang=python option generates a Python entry point.
  • The --no-deploy option keeps the project on your computer for now.
  • The --no-git option skips creating a Git repository.

C3 installs the project dependencies. This includes the local copy of Wrangler used throughout the project.

  • Confirm the generated project files by running:
ls python-d1-api
ls python-d1-api/src

What should this show?

The first command lists the Wrangler configuration and project files. The second command lists the generated Python entry-point source.

Your project shell is ready. The Worker now has the configuration and Python source needed for local development.

Did the project creation stop?

  • Check that your terminal still has an internet connection.
  • Confirm that the folder name is exactly python-d1-api.
  • Run the creation command again after removing any incomplete folder with the same name.

Get help with the scaffold. You can also ask in the Cloudflare Developers Discord.

Connect Wrangler to Cloudflare

Wrangler uses OAuth to connect your terminal session to your Cloudflare account. Your credentials stay in the browser during this flow.

  • Move into python-d1-api and start the Wrangler login flow by running these commands:
cd ~/Desktop/python-d1-api
npx wrangler login

What happens during login?

  • The first command moves your terminal into the Worker project.
  • The second command opens Cloudflare authorization in your browser.
  • Complete the Cloudflare authorization flow in the browser window.
  • Return to your terminal after the browser confirms the connection.
  • Verify the authenticated account by running:
npx wrangler whoami

What does this check prove?

Wrangler retrieves information about the authenticated account. A successful result proves that later database and deployment commands can reach Cloudflare.

You'll see details for your signed-in Cloudflare account. Your terminal is now connected to the account that will own the Worker.

Still not authenticated?

  • Check that you completed the browser authorization before returning to the terminal.
  • Run the login command again if the browser window was closed early.
  • Confirm that your browser signed in to the intended Cloudflare account.

Help me fix Wrangler authentication.

Run the Worker locally

Wrangler development mode starts a local Workers runtime from the generated configuration. Requests to its local URL run the Python template on your computer.

Before you start the server, what response do you expect from the untouched template?

  • Start the local development server by running this command:
npx wrangler dev

What does development mode do?

  • Wrangler reads the project configuration to find the Python entry point.
  • The local Workers runtime executes that entry point whenever it receives a request.
  • The command keeps running so Wrangler can serve new requests.
  • Leave the development server running in your terminal.
  • Open http://localhost:8787 in your browser.

You'll see the response from the generated Python template. That confirms the python-d1-api Worker is serving requests locally.

Can't see the template response?

  • Confirm that the Wrangler development command is still running in the terminal.
  • Check that your terminal is inside ~/Desktop/python-d1-api.
  • Use the local URL printed in your terminal if Wrangler selected a different available port.

Help me debug the local Worker.

Your Python Worker is running locally and answering requests. Next up, you'll add a route that returns a structured JSON response.

Add a JSON API Route

Your local Cloudflare Worker already answers requests with the template response. The next goal is to give one URL path its own structured response.

You will add a JSON API route at /api. This creates a predictable response shape for the database rows you will return later.

In this step, get ready to:
  • Add URL path routing to the Python request handler.
  • Return structured JSON from the new route.
  • Confirm the response body plus its content type locally.
Route requests to /api

The request handler receives every local request. Reading each URL path lets the same Worker return a different response for /api.

  • In the code editor from earlier, select src/entry.py inside the python-d1-api folder.
  • Replace the file contents with the code below:
from urllib.parse import urlparse
from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        # Parse the URL so each path can return its own response
        url = urlparse(request.url)

        if url.path == "/api":
            # Give API clients a predictable set of values
            data = {"greeting": "Hello, World!", "status": "ok"}
            return Response.json(data)

        # Keep the template response for every other path
        return Response("Hello World!")

What Does This Code Do?

  • The urlparse(request.url) call separates the request URL into useful parts.
  • The url.path == "/api" condition selects requests for the new route.
  • The data dictionary defines the response shape.
  • The Response.json(data) call converts that dictionary into a JSON response.
  • The same call sets the response content type to application/json.
  • Save src/entry.py.

The running development server reloads the updated Worker. Your next request uses the new handler.

Before you check the route, what response shape do you expect the browser to display?

  • Return to the browser tab showing your local Worker.
  • Add /api to the end of the local Worker URL.
  • Press Enter to load the route.

You should see a JSON object containing the greeting Hello, World! plus the status ok.

Still Seeing the Template Response?

Check that the browser URL ends with exactly /api. Confirm that the route condition sits inside the fetch() method.

Compare the indentation in src/entry.py with the code above. Python uses indentation to decide which lines belong to the route condition.

Help me debug my Python Worker route.

✔️ Awesome, I've got everything!

Your saved handler now serves structured JSON from /api.

ⓧ I'd like to double check the full code

from urllib.parse import urlparse
from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        # Parse the URL so each path can return its own response
        url = urlparse(request.url)

        if url.path == "/api":
            # Give API clients a predictable set of values
            data = {"greeting": "Hello, World!", "status": "ok"}
            return Response.json(data)

        # Keep the template response for every other path
        return Response("Hello World!")
Verify the response contract

The response body proves the data shape. The response header tells clients to parse that body as JSON.

Your first terminal session is still running the development server. A second terminal keeps that process active while you inspect the response.

  • Copy the full local /api URL from your browser address bar here: your local /api URL.
  • Open a second terminal tab with your terminal's new-tab control.

Before you run this check, which two parts of the response do you expect curl to reveal?

  • Check the response headers plus the body by running this command:
curl -i [[LOCAL_API_URL="your local /api URL"]]

What Does This Check Prove?

The -i option includes the HTTP response headers above the body. This lets you inspect the route's format in one request.

A content-type header containing application/json tells clients how to parse the response.

You should see a successful response with application/json in the headers. The body should contain greeting plus status with the values you saw in the browser.

Missing the JSON Header?

Confirm that the route returns Response.json(data). A plain Response(data) does not apply the same JSON response behavior.

Check that the development server remains active in the first terminal tab. Restart the local process from the earlier step if it has stopped.

Help me inspect my local API response.

You have turned the template Worker into a working local API with a defined response contract. Next, you will create the D1 database that supplies real rows to this route.

Create and Populate a D1 Database

Your /api route already returns structured JSON from the local Worker. The next goal is to give that API stored data it can read.

Cloudflare D1 is a managed SQLite database that sits beside your Worker. You can manage its data through Wrangler.

You'll define a schema for an items table. You'll load three sample rows before using a command-line query to confirm that they exist.

In this step, get ready to:
  • Create the D1 database.
  • Prepare an items table with sample rows.
  • Confirm the stored rows with a Wrangler query.
Create the D1 database

A D1 database lives in your Cloudflare account. Wrangler returns a database ID that connects this resource to your Worker configuration later.

  • Keep the terminal running your Wrangler development server untouched.
  • Switch to a second terminal tab inside the python-d1-api folder.
  • Send the database creation request through Wrangler by running this command:
npx wrangler d1 create python-d1-api-db

What does this command do?

Wrangler creates python-d1-api-db as a remote D1 database in your Cloudflare account.

The output includes the database UUID needed for your Worker configuration. Recording it now keeps the next connection step precise.

  • Copy the database ID from Wrangler's output into your D1 database ID.

Good progress. Your API now has a remote database waiting for its first table.

Database creation failed?

Check that the second terminal is still authenticated with the same Cloudflare account. Confirm that your internet connection is active before retrying the command.

If Wrangler reports a name conflict, check your Cloudflare account for an existing database named python-d1-api-db.

Help me troubleshoot this D1 database creation problem.

Create and fill the items table

A table gives each record the same structure. The primary key gives every item a unique identifier.

  • Create the remote items table by running this command:
npx wrangler d1 execute python-d1-api-db --remote --yes --command="CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT NOT NULL, description TEXT NOT NULL)"

How is the table structured?

  • The id column stores a unique integer for each row.
  • The name column stores the item name as text.
  • The description column stores a required text description.

Wrangler reports that the remote operation succeeded. That result confirms that D1 accepted the table definition.

Table creation failed?

Confirm that the command includes --remote so Wrangler targets the database in your Cloudflare account. Check that python-d1-api-db matches the database name from the previous substep.

If Wrangler reports that the table already exists, avoid running the creation command again. Continue with the insertion command below.

Help me diagnose this D1 table creation problem.

Sample rows make the table useful for the API route you connect later. Each row gets its own name and description.

  • Insert three sample items into the remote table by running this command:
npx wrangler d1 execute python-d1-api-db --remote --yes --command="INSERT INTO items (name, description) VALUES ('Notebook', 'Capture API ideas'), ('Keyboard', 'Write Python quickly'), ('Mug', 'Keep deployment fuel close')"

What does this insertion add?

The command adds three rows with one SQL statement. D1 assigns each row an id through the table's integer primary key.

The sample names make the final query easy to inspect. You can identify a missing row immediately.

Wrangler confirms that the remote insertion succeeded. Your D1 database now contains data for the Worker to read.

Rows were not inserted?

Confirm that the earlier table command succeeded before retrying the insertion. Check each quote around the sample text if Wrangler points to invalid SQL.

Help me fix this D1 insertion command.

Verify the sample rows

A successful insertion message confirms that D1 accepted the write. A direct selection shows the exact records now stored in the table.

Before you run the query, which three item names do you expect Wrangler to return?

  • Read the stored rows from the remote database by running this command:
npx wrangler d1 execute python-d1-api-db --remote --command="SELECT id, name, description FROM items ORDER BY id"

What does this query check?

The query reads the three columns from every row in items. It sorts the results by id so the insertion order is easy to inspect.

You'll see three rows containing Notebook, Keyboard, and Mug. Each row also includes its description and numeric ID.

Query returned no rows?

Confirm that the query targets python-d1-api-db with the --remote flag. Review the insertion output to confirm that D1 accepted the three rows.

Help me find why my D1 query returned no sample rows.

That's the data layer ready: your remote D1 database contains a verified items table. Next, you'll bind that database to the Python Worker so the API can return these rows.

Query D1 From Your Python API

Your /api route already proves your code runs on Cloudflare Workers as JSON. Your sample rows are already stored in Cloudflare D1.

A D1 binding gives your Python code a named connection to that database. You will configure the connection with Wrangler. Then you will use it to serve the rows through /items.

In this step, get ready to:
  • Bind the python-d1-api-db database to your Worker.
  • Query the items table from a new /items route.
  • Verify the existing /api route plus the new database route.
Bind D1 to your Worker

Wrangler bindings connect Worker code to Cloudflare resources. The binding name DB makes this database available inside the request handler as self.env.DB.

  • Switch back to the editor containing your python-d1-api project.
  • Open wrangler.jsonc from the project file list.
  • Add a comma after the final existing top-level setting.
  • Paste your database ID from the earlier D1 creation result into this project variable: your D1 database ID.
  • Add the D1 binding before the closing brace by copying this configuration:
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "python-d1-api-db",
      "database_id": "[[DATABASE_ID="your D1 database ID"]]",
      "remote": true
    }
  ]

What does this configuration do?

  • The binding value exposes the database to Python as self.env.DB.
  • The database_name value identifies python-d1-api-db in your Cloudflare account.
  • The database_id value selects the exact database you created.
  • The remote setting lets local development read the sample rows stored in the cloud database.
  • Save wrangler.jsonc.
  • Return to the terminal running your development server.

Wrangler reloads the Worker configuration. You should see the DB binding listed among the available bindings.

Does the binding fail to load?

Check that database_id contains the complete database ID. Check that the setting above d1_databases ends with a comma.

Restart the development server with the same command you used earlier if Wrangler does not reload the configuration.

Help me check my D1 binding configuration

Add the items route

The new route turns a browser request into a database query. It returns only the row objects so the response stays focused on your item data.

  • Open src/entry.py from the python-d1-api project.
  • Locate the existing /api branch inside fetch().
  • Add the new branch before the fallback response by copying this code:
        if pathname == "/items":
            # Read every sample item through the D1 binding.
            query = await self.env.DB.prepare(
                "SELECT id, name, description FROM items ORDER BY id"
            ).run()
            return Response.json(query.results)

What does this code do?

  • The /items condition keeps the database query scoped to one route.
  • The SQL statement reads the three columns from every row in items.
  • The ORDER BY id clause keeps the response in a predictable order.
  • The run() call executes the prepared query.
  • The query.results value contains the returned row objects.
  • Save src/entry.py.

Before you load the new route, what three fields do you expect each returned object to contain?

  • Switch back to the browser tab showing your local Worker.
  • Replace the current path with /items.
  • Press Enter.

You should see a JSON array containing your sample rows. Each object includes id, name, plus description.

That is the full local request path working. Your database rows now travel through the Python API.

Do you see an empty result or database error?

An empty result usually means local development is using a separate local database. Confirm that the D1 binding contains "remote": true.

A database error can also come from a mismatched binding name. Confirm that "binding": "DB" matches self.env.DB exactly.

Help me debug my items route

✔️ Awesome, I've got everything!

Your Python source now keeps the original JSON route while adding the D1-backed items route.

ⓧ I'd like to double check the full code

from workers import Response, WorkerEntrypoint
from urllib.parse import urlparse

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        # Parse the path so this Worker can serve multiple routes.
        pathname = urlparse(request.url).path

        # Return the original JSON response.
        if pathname == "/api":
            return Response.json({"message": "Hello from Python Workers"})

        if pathname == "/items":
            # Read every sample item through the D1 binding.
            query = await self.env.DB.prepare(
                "SELECT id, name, description FROM items ORDER BY id"
            ).run()
            return Response.json(query.results)

        # Return a clear response for paths this API does not handle.
        return Response("Not found", status=404)
Verify both local routes

A new route can accidentally disturb an existing branch in the same request handler. This final check proves that both paths still produce the correct response.

Before you check, do you expect the two routes to return the same JSON shape?

  • Return to the browser tab showing your local Worker.
  • Replace the current path with /api.
  • Press Enter.

You should see the original JSON response from the earlier route.

  • Replace the path with /items.
  • Press Enter.

You should see the inserted database rows as a JSON array. The response should include values from the id, name, plus description columns.

Your local API now reads live rows from D1 while preserving its original route. Next up, you will deploy the Worker and watch requests arrive through its logs.

Deploy and Monitor Your API

Your Cloudflare Worker can already query D1 on your machine. The API still needs a public address before anyone else can reach it.

A Wrangler deployment moves the request path to Cloudflare. A live log tail then proves that real requests are reaching the deployed Worker.

In this step, get ready to:
  • Deploy the Python Worker to its public URL.
  • Test both public JSON routes.
  • Watch requests arrive in the live logs.
Deploy the Worker

Deployment packages your existing Python code with its configuration. Cloudflare uses that configuration to connect the deployed Worker to the same database through the DB binding.

  • Switch back to the terminal running your local development server.
  • Stop the local development server by pressing Ctrl+C.
  • Deploy the python-d1-api project by running this command:
npx wrangler deploy

What does this command do?

  • Wrangler packages the Worker source for Cloudflare's runtime.
  • The existing configuration attaches python-d1-api-db through the DB binding.
  • The deployment output gives you the public workers.dev address.
  • Record the public URL from the deployment output here: https://python-d1-api.your-subdomain.workers.dev.

You should see the DB binding in the deployment summary. You should also see a public URL ending in workers.dev.

Your deployment is live. The API now has a public address backed by the configured database.

Deployment not completing?

  • Confirm the terminal is inside python-d1-api.
  • Check that the Wrangler configuration still maps DB to python-d1-api-db with the database ID from earlier.

Help me diagnose my Worker deployment

Verify the public routes

A successful deployment message confirms that Cloudflare accepted the Worker. Testing each public route confirms that the deployed code behaves like the local version.

Before you load the first route, do you expect its response to match the JSON you tested locally?

  • Open a new browser tab.
  • Visit https://python-d1-api.your-subdomain.workers.dev with /api added to the end.

You should see the same JSON response you tested locally. This confirms that the deployed /api route is responding.

Before you switch routes, do you expect the deployed database query to return the sample rows?

  • Replace /api with /items in the browser address bar.

You should see the inserted rows with their id, name, and description values. This proves that the deployed env.DB binding can query python-d1-api-db.

Public items route failing?

  • Confirm the browser URL ends with /items.
  • Recheck the deployed DB binding in the deployment output when /api works but /items fails.

Help me debug my deployed items route

Tail production requests

A live tail streams request activity from the deployed Worker into your terminal. It gives you direct evidence that traffic is reaching the public API.

  • Return to the terminal used for deployment.
  • Start the live log tail by running this command:
npx wrangler tail

What does the tail show?

Wrangler keeps the terminal session active while it listens for requests to the deployed Worker. Each new request produces a log entry with details about the route and request method.

The terminal should remain open while Wrangler waits for incoming traffic.

Tail session not connecting?

  • Confirm the tail command is still running in the deployment terminal.
  • Refresh the public browser tab after the tail session connects.

Help me connect Wrangler tail

Before you refresh /items, do you expect the terminal to stay quiet or record a new request?

  • Return to the browser tab showing /items.
  • Refresh the page.

You should see a new GET request for /items in the tail output. The browser should continue showing the database rows.

  • Replace /items with /api in the browser address bar.

You should see another request appear for /api. The browser should show the deployed JSON response.

That's the full production loop working. Your public Python API can read from D1 while Wrangler shows each request arriving in real time.

Secret mission

Run a Production Smoke Test

A successful deployment does not prove that every route works in production. Build a repeatable smoke test that checks both public routes before tracing a database-backed request through the live logs.

Clean Up Your Resources

Clean Up Your Resources

You can keep your API available, pause local log tailing, or delete its cloud resources. The Cloudflare Workers free plan lets the Worker and D1 database stay in place without ongoing cost.

Resources you used:

  • Cloudflare Worker python-d1-api with its public workers.dev URL, /api route, /items route, and DB binding.
  • D1 database python-d1-api-db with its items table and sample rows.
  • Wrangler log-tail process connected to the deployed python-d1-api Worker.

Keep everything running

No action is needed. Choose this if you want to keep using the public API or continue building the project.

  • Your public workers.dev URL continues to serve the /api and /items routes.
  • The /items route continues to read the sample rows from python-d1-api-db.
  • Wrangler log tailing stays connected while its terminal session remains open.

Pause - I'll come back to this later

Pause the local log-tail process to free your terminal. Your deployed Worker and D1 database remain available on Cloudflare.

  • Press Ctrl+C in the terminal running Wrangler log tailing.

You should see your normal terminal prompt again. The public workers.dev URL continues to serve both routes.

Delete - I don't want to use this again

This option removes the deployed Worker and its D1 database. Your local project files remain on your computer.

Deletion Is Permanent

Deleting python-d1-api takes both public routes offline.

Deleting python-d1-api-db permanently removes the items table and its sample rows.

  • Stop Wrangler log tailing by pressing Ctrl+C in its terminal.

You should see your normal terminal prompt again.

  • Go to the Workers list in your Cloudflare dashboard.
  • Select python-d1-api.
  • Open the settings page for this Worker.
  • Use the Worker deletion control to remove python-d1-api.
  • Complete the on-screen confirmation for python-d1-api.

The Worker should disappear from your Workers list. Its public workers.dev URL no longer serves the /api or /items route.

  • Go to the D1 database list in your Cloudflare dashboard.
  • Select python-d1-api-db.
  • Open the settings page for this database.
  • Use the database deletion control to remove python-d1-api-db.
  • Complete the on-screen confirmation for python-d1-api-db.

You should no longer see python-d1-api-db in your D1 database list. The items table and its sample rows are now removed.

Nice Work!

Nice Work!

You did it! Your Python API now runs on Cloudflare Workers at a public URL. It returns live database rows from the edge.

What you learned:

  • Built a Python Worker with an /api route that returns JSON with the correct content type.
  • Connected a D1 database through the DB binding. Your /items route now returns rows from the items table.
  • Deployed the python-d1-api Worker to a public workers.dev URL. You also watched requests reach the deployed Worker through live logs.
  • Secret Mission: Took on an optional challenge to extend your Python API skills further.

Ready to quiz yourself?