Hosting Django i Python, bez stawiania serwera.

1. Django is a framework for people who want control over the server.

Django was designed from the start to give you full control over the data layer, authorization, and project structure. This naturally appeals to developers who want the same control over the environment where their application runs, not just over the Python code itself.

On Saplo, you can deploy a Django 5.x app with your choice of Python version, either 3.11 or 3.12 with 3.12 as the default. The nginx virtual host and gunicorn WSGI server are configured automatically, so you do not need to write systemd or nginx configuration files from scratch.

The manifest specifies a minimum of 256 MB RAM. This is a low entry point, but real Django apps with an ORM, sessions, and middleware rarely run comfortably below 2 GB RAM, especially when several users are active at the same time. Box M is therefore a practical minimum for anything more than a prototype.

2. SSH, migrations, and application management from the terminal

From Box M, full SSH access with sudo lets you run standard Django commands directly from the terminal, including manage.py migrate, collectstatic, and createsuperuser. There is no need to use a separate hosting admin panel that does not understand Django commands.

Git deploy updates the application code whenever you push to the configured branch. Database migrations and further deployment steps, such as restarting the gunicorn process and collecting static files, still require you to run commands manually over SSH. For a developer familiar with Django, this is a standard step.

Celery and background tasks, such as reminders, sending emails, and queue processing, can run as a separate process in the same container with the appropriate systemd configuration. This is a common part of the architecture for Django apps with asynchronous tasks. Monitor the web process and Celery worker memory usage separately, because both share the same RAM limit for the entire application container on a given Box, especially when many Celery tasks run in parallel in the background.

3. Database for Django

By default, Django uses a relational database. On Saplo, Postgres and MySQL are available as separate database modules that you deploy as containers in your own Docker Compose setup. They are not paid add-ons priced separately from the application hosting.

For projects that require Redis, such as a Celery broker or session cache, a separate Redis module is available. You can deploy it on the same Box as your Django app without using an external Redis service outside Saplo's infrastructure.

4. Django vs. a ready-made Python PaaS

Python-focused PaaS platforms often charge per instance or based on hourly resource consumption, with prices quoted in dollars. With real production traffic in Poland, this makes budgeting in PLN more difficult and exposes you to exchange-rate fluctuations on your bill.

On Saplo, the price is fixed, annual and denominated in PLN, regardless of how many requests per second the application handles at any given time. For a project with irregular traffic (e.g. an internal company application used only during business hours), this is easier to estimate than usage-based hourly billing.

5. Who it is for

For a developer building a web app or internal company system with Django, Box M with full SSH provides a production-ready environment where you can run migrations and configure the app without setting up a server from scratch.

For a team developing a larger app with Celery, Redis, and a separate database, Box L has enough RAM headroom for several processes running in parallel in the same container or alongside separate database modules.

For an agency building B2B systems with Django, a single Box can run many independent Django installations at once, each in its own container with its own database.

6. Deploying your first Django app on Saplo

After setting up a Django application with your chosen Python version, connect a Git repository so the code updates automatically when you push. Then use SSH to run manage.py migrate and manage.py createsuperuser for the first time, giving you access to the Django admin panel.

You set environment variables (SECRET_KEY, a database connection string, external API keys) in the application panel or in a.env file in the container, following standard Django configuration practice by keeping them outside the code repository.

If your app uses Celery for background tasks, configure an additional systemd process in the container, with a Celery worker and, optionally, Celery beat for scheduled tasks. Use Redis as the broker and deploy it as a separate module on the same Box.

Configure static files (collectstatic) on your Box's nginx virtual host so the Gunicorn process does not have to serve them. The web server can handle these files faster and with lower RAM usage.

After the first deployment, monitor Gunicorn and Django logs over SSH to catch configuration errors, such as leaving DEBUG=True enabled in production, before real user traffic reaches the app.

7. Django REST Framework and APIs on Saplo

Django applications built as APIs using Django REST Framework run on the same Box as traditional template-based applications. The difference lies in the Django code, not in how Saplo hosts it.

For an API that uses token authentication, keep secrets such as JWT keys and API keys for external services in the container's environment variables, not in the repository code. This follows security best practices.

CORS and other security headers are configured within the Django application itself through middleware. The Saplo reverse proxy passes these headers through unchanged, so standard Django configuration works without additional steps.

For an API that serves a frontend hosted on another domain (e.g. a Next.js application from a separate Box or external hosting), review the ALLOWED_HOSTS and CORS_ALLOWED_ORIGINS settings in Django.

8. Django configuration security in production

A common mistake when deploying Django to production is leaving DEBUG=True enabled. If an application error occurs, this can expose the full stack trace, environment variables, and code snippets to users, creating a serious information leak about the application's internal structure.

The SECRET_KEY used by Django to sign sessions and tokens should be unique for each deployment and should never be committed to the code repository. Instead, set it as an environment variable in the application configuration on Saplo, separately from the source code itself.

ALLOWED_HOSTS should contain exactly the domains where the application is available, not a wildcard that allows every host. This provides basic protection against Host header injection attacks, which is especially important for applications that accept data from users on the internet.

Logically separate static files from user media (uploads), serving the application's static files through nginx and user-uploaded files through a separate mechanism with appropriate permissions. This prevents users from uploading and executing a malicious script on the server.

Updating Django itself and the Python packages listed in requirements.txt should be part of your regular workflow. Just like in the Node.js ecosystem, outdated dependencies are a common attack vector for known vulnerabilities with available fixes and are routinely found by automated vulnerability scanners.

For applications that store users' personal data, it is worth deliberately configuring session settings (expiration time, Secure and HttpOnly cookie flags). Django supports them natively, but they require explicit configuration in the project settings and do not work correctly with the default values in every scenario. Before the first production deployment, review this configuration along with the full list of Django security settings instead of discovering a missing setting only after a real security incident.

9. The Python ecosystem and packages that support Django applications

Python and Django have a rich package ecosystem on PyPI that supports common web application needs, including authentication and authorization, external API integrations, PDF report generation, and payment processing. This lets you build application features with proven, ready-made solutions instead of writing everything from scratch.

On Saplo, full SSH access with sudo, available from Box M, lets you install any Python packages through the standard pip package manager without restrictions imposed by the hosting platform. This differs from some closed PaaS environments that support only a limited set of libraries.

The choice between popular Django extensions, such as Django REST Framework for APIs, Django Channels for WebSockets, and Django CMS for content management, is entirely up to the developer building the application. The hosting provider imposes no architectural constraints upfront.

Changing the Python version from 3.11 to 3.12 is available as an app configuration option. This lets you use new language features and performance improvements without migrating to another provider simply to change your runtime environment version.

For teams building more complex Django applications (with Celery, Redis and multiple external integrations), full control over the environment via SSH, combined with Saplo's ready-made base modules, provides flexibility similar to a traditional VPS, but with a shorter deployment time for the base environment itself.

10. Test database migrations before production deployment

Test Django migrations that change the database schema, such as adding a column or changing a field type, on a database copy first rather than directly on the production database. A migration error can lead to data loss or downtime while the migration is running.

Taking a Box backup (available from Box L) before a major migration provides an additional safeguard, allowing you to return to the pre-migration state if something goes wrong. However, making a separate manual database backup immediately before the migration itself is also a best practice.

Irreversible migrations, such as removing a column containing data, require special care. If an error occurs, deleted data can only be restored from a backup taken before the migration, not by reversing the migration in Django.

For teams working on the same database, establish a clear procedure for running production migrations, including who runs them, when they run, and which test must pass. This prevents two people from attempting conflicting migrations on the same database at the same time.

Full SSH access with sudo on Saplo, available from Box M, gives you all the tools needed to run migrations safely. However, the process discipline of testing, backing up, and only then running the production migration remains the responsibility of the development team managing the project.

11. Summary: Django on Saplo for developers who want control

Full SSH access with sudo, your choice of Python version, and a ready-made gunicorn and nginx setup give Django developers exactly the control and convenience they need for production deployments. Standard manage.py commands work as expected, while the entire server layer around them is already in place, so you don't have to build it from scratch for every new Django project. For teams managing multiple Django projects at once, this repeatable setup means each new project gets up and running as quickly as the first, without repeating the same familiar server configuration steps. It also reduces the risk of small, hard-to-spot configuration differences between projects, which are often a source of subtle production bugs on servers you manage yourself.