Update the celery documentation domain

src/best-practices/index.md

@@ -4,7 +4,7 @@
 
 Tasks are only removed from a queue when they are acknowledged ("acked") by the worker that received them. The [`acks_late`](https://docs.rs/celery/*/celery/struct.CeleryBuilder.html#method.acks_late) setting determines when a worker will ack a task. When set to `true`, tasks are acked after the worker finishes executing them. When set to `false`, they are executed right before the worker starts executing them.
 
-The default of `acks_late` is `false`, however if your tasks are [idempotent](https://docs.celeryproject.org/en/stable/glossary.html#term-idempotent) it's strongly recommended that you set `acks_late` to `true`. This has two major benefits.
+The default of `acks_late` is `false`, however if your tasks are [idempotent](https://docs.celeryq.dev/en/stable/glossary.html#term-idempotent) it's strongly recommended that you set `acks_late` to `true`. This has two major benefits.
 
 First, it ensures that if a worker were to crash, any tasks currently executing will be retried automatically by the next available worker.
 

src/coming-from-python/index.md

@@ -6,7 +6,7 @@ In some cases this means the Rust equivalent is a little more verbose or takes a
 
 ## Registering tasks
 
-In Python you can register tasks by dynamically importing them at runtime through the [`imports`](https://docs.celeryproject.org/en/stable/userguide/configuration.html#imports) configuration field, but in Rust you need to manually register all tasks either as parameters to the [`app`](https://docs.rs/celery/*/celery/macro.app.html) macro or using the [`Celery::register_task`](https://docs.rs/celery/*/celery/struct.Celery.html#method.register_task) method:
+In Python you can register tasks by dynamically importing them at runtime through the [`imports`](https://docs.celeryq.dev/en/stable/userguide/configuration.html#imports) configuration field, but in Rust you need to manually register all tasks either as parameters to the [`app`](https://docs.rs/celery/*/celery/macro.app.html) macro or using the [`Celery::register_task`](https://docs.rs/celery/*/celery/struct.Celery.html#method.register_task) method:
 
 ```rust,no_run,noplaypen
 # #![allow(non_upper_case_globals)]

src/guide/defining-tasks.md

@@ -53,7 +53,7 @@ There are two error kinds in particular that are meant as catch-alls for any oth
 
 ## Positional vs keyword parameters
 
-Within the [Celery protocol](https://docs.celeryproject.org/en/latest/internals/protocol.html#version-2)
+Within the [Celery protocol](https://docs.celeryq.dev/en/latest/internals/protocol.html#version-2)
 task parameters can be treated as either `args` (positional) or `kwargs` (key-word based).
 Both are supported in Rusty Celery, which means you could call the Rust `add` task defined above from another language like Python in any of the following ways:
 

src/quick-start.md

@@ -97,7 +97,7 @@ From another terminal you can then send tasks to the worker from Rust with
 cargo run --example celery_app produce
 ```
 
-If you have Python and the [celery](http://www.celeryproject.org/) Python library installed, you can also consume or produce tasks from the Python app with
+If you have Python and the [celery](https://docs.celeryq.dev/en/stable/) Python library installed, you can also consume or produce tasks from the Python app with
 
 ```bash
 python examples/celery_app.py consume

src/what-is-celery.md

@@ -33,7 +33,7 @@
 
 # What is Rusty Celery?
 
-Simply put, this is a Rust implementation of the [Celery](http://www.celeryproject.org/) protocol for producing and consuming asyncronous tasks with a distributed message broker.
+Simply put, this is a Rust implementation of the [Celery](https://docs.celeryq.dev/) protocol for producing and consuming asyncronous tasks with a distributed message broker.
 It comes with an idiomatic async API driven by the performant [tokio.rs](https://tokio.rs/), and above all an emphasis on safety.
 
 ### How does it work?