---
title: "Cool new features for Django-Hurricane"
description: "We have added some more features to our open source project, Django-Hurricane. Check them out here! ✔ Django ✔ Open Source ✔ New Features"
canonical_url: "https://www.blueshoe.io/blog/new-features-django-hurricane/"
---
> Index of every page on this site: [llms.txt](https://www.blueshoe.io/llms.txt)
We are pushing the development in the areas of Django and Kubernetes with our open-source project **Django-Hurricane**. Today, we’d like to show you some **new features**.
Towards the end of 2020, we told you about our new **open-source** project Django-Hurricane. You can read our blog post about the launch here. With this project, we want to drive the **Django and Kubernetes** development forward and make our developers’ lives easier by eliminating a lot of routine jobs that pop up during the project set-up, transferring them to a robust framework.
We also worked on the to-do list in the [GitHub Repository](https://github.com/django-hurricane/django-hurricane) and are now able to show you some new features of [Django-Hurricane](https://django-hurricane.io/).
Documentation
We have done extensive work on the [documentation](https://django-hurricane.readthedocs.io/en/latest/). Apart from the **user guide**, there’s also a low-level [API](https://www.blueshoe.io/our-services/api-development-company/) documentation. The user guide provides helpful information about the use of **Django-Hurricane**, such as the available command options, useful tips for the configuration as well as general information about the individual components of Django-Hurricane. In the [API](https://www.blueshoe.io/our-services/api-development-company/) documentation, you’ll be able to look up the features of those individual components.
Running management commands
We have also implemented a feature which allows for the **management commands** to be specified and run directly in the ‘serve’ command. The new **command options** are:
- no-metrics: deactivate the collection of metrics.
- command: the repeatable instruction that defines the management commands. The commands are carried out before the HTTP server is started. As the command can be run more than once, it can be repeatedly defined with those different management commands that might also have further options. In this case, you have to specify both the options and the name of the command in a string.
A command using the management commands could look as follows:
```docker
python manage.py serve --command makemigrations --command “compilemessages --locale =de_DE”
```
Probe Endpoints
Probe endpoints can now be defined separately using the ‘serve’ command. The options for this are:
- startup-probe: the path for the startup endpoint (default: /startup).
- readiness-probe: the path for the readiness endpoint (default: /ready).
- liveness-probe: the path for the liveness endpoint (default: /alive).
- req-queue-len: the threshold for the request queue. If this threshold is exceeded, the readiness probe will trigger a request with the status code 400.
Webhooks for probe events
In addition to this, we have also implemented a new feature for [Django-Hurricane](https://django-hurricane.io/): the ability to send **webhooks** to a specific address. By now, there are three webhooks which correspond to the three probes. The first one is the startup webhook. It is run after the start of the HTTP server and sent to the specified address. Should the application have failed to start, a startup webhook with the status ‘failed’ is initiated. After this, the application is stopped.
The liveness and readiness webhooks are initiated after the respective **probe requests**. The webhooks are only run following a change in state – i. e. when the first probe request occurs, which changes the state from ‘None’ to ‘Healthy/Unhealthy’, as well as when the state changes from ‘Healthy’ to ‘Unhealthy’ or from ‘Unhealthy’ to ‘Healthy’. In the case of a webhook with the status ‘failed’, a corresponding error traceback is also sent.
In order for the webhooks to be sent at all, the URL has to be provided along with the **webhook command**. The command option is called ‘webhook-url’ and is provided as a URL for webhooks. The entire command for running the application together with webhooks would look as follows:
```docker
python manage.py serve --webhook-url „http://“
```
Every one of the webhooks also contains certain data:
- Status: *‘failed’* or *‘succeeded’* – this depends on whether the probe is run successfully or whether it fails.
- Type: *‘startup’*, *‘readiness’* or *‘liveness’*.
- Timestamp: the moment when the webhook was initiated.
- Hostname: the name of the computer or server.
- Version: the Hurricane version.
- Error trace: if the webhook has the status *‘failed’*, the server will send the error message along with the error path.
Despite all our hard work on the [Django-Hurricane to-do list](https://django-hurricane.readthedocs.io/en/latest/todos.html) in the last few months, we’ve still got some unchecked boxed left. We’d therefore be very grateful for any help with the further development of Django-Hurricane as well as any of our other **open-source projects**. We’re already excited about the new challenges of the development and are looking forward to ticking off some more boxes in our GitHub Repository to-do list.
OUR KUBERNETES PODCAST
Tools for the Craft: Navigating the Kubernetes ecosystem
Michael and Robert are talking about the various options developers have for running remote Kubernetes development environments.
More editions of our podcast can be found here:
## Sitemap
See the full [sitemap](https://www.blueshoe.io/sitemap.md) for all pages.