This post will take you through my solution of Jane Street’s July 2026 Puzzle, ‘Pent-Up’ Frustration 3 / Knight Moves 7. As always, I recommend you try it out yourself before reading this article!

This was a fun one that is pretty straightforward once you grasp the rules. This is essentially a constraint satisfaction problem. We can find the solution sequence of knight’s moves with some clever backtracking.

Setup

Those constraints are:

• Never leave the grid
• Never revisit a space
• Visit each tower
• One tower per pent(tetr)omino
• If our knight reaches a tile on one of the moves where it is supposed to “write down” its score, its score after that move must match the score on the tile

Let’s set some notation. Let’s identify the board’s positions by tuples \((x,y,z)\), where \(x=0\) on the far left column, \(y=0\) on the bottom row, and \(z=0\) if the knight is not on a tower or \(z=1\) if the knight is on a tower. The knight’s moves \((dx\ dy\ dz)\) are signed permutations of \(\{2,1,0\}\), where \(dz\) can only be \(+1\), \(0\), or \(-1\).

We’ll call the knight’s score after \(i\) moves \(S_i\), the set of moves after which our knight writes down its score \(R = \{0, 3, 6, 9, 12, 15, 18, 18+k \dots 18+5k\}\) for some \(k > 3\), the score written down on position \((x,y)\) \(\operatorname{hint}(x,y)\), and our position after \(i\) moves \((x_i, y_i, z_i)\).

I think a crucial first insight to solving this problem is that the towers’ positions are not a separate optimization problem from the knight’s move. A proper sequence of knight’s moves will imply the proper tower positions. So, I think it is useful to translate the above constraints to:

• \(0 \le x \le 7\), \(0 \le y \le 7\), \(0 \le z \le 1\)
• Never revisit an \((x,y)\)
• Exactly once for each region, occupy a position in that region with \(z=1\)
• For each move \(i\), if \(i \in R\), \(S_i = \operatorname{hint}(x_i, y_i)\)

Early exploration

Once I grokked the constraints and movement, I took a few minutes to find which of the nearby number tiles could possibly be the knight’s position after move 3. I found that the only way to get to a correct hint score was to start on a tower. The first 4 positions including our start must be:

Let’s look at that path on the board. Our moves are numbered in the top left corner, intermediate scores are shown in faint type, and towers are marked by triangles in the upper right corner.

Then, only using the possible moves from this position, you can enumerate the possible sequences of scores \(S_1\) through \(S_6\).

Which of these sequences have an \(S_6\) that is in our set of hints?

Ok, so there is one option there. \(S_6\) must be 16. Now, what sequence of moves will get us there?

Now, we see that we have three options for moves 4 through 6. Think about this like sudoku: we’ll assume one is correct, and then run the exact same analysis of possible point sequences and legal moves to \(S_9\). If there is no legal \(S_9\) under our assumption for moves 4 through 6, then we know that assumption is wrong and we can eliminate that option. If there are multiple possible paths there, then we can repeat the same process recursively.

Doing that by hand would take forever, so luckily, there are algorithmic methods for solving this exact kind of problem.

Backtracking: depth-first search with pruning

This puzzle is a constraint satisfaction problem. We want to construct a set of moves that satisfy all of the rules. Imagine our knight’s paths-so-far as nodes in a tree. Each subsequent move takes our knight to a child node and eventually our puzzle’s solution will be on a leaf.

The work I showed to get us to move 6 in the last section is a classic application of backtracking, a common approach for this sort of problem. We will use depth-first search (DFS) to build a path of nodes while checking our list of constraints to eliminate paths that are in violation. If all of a node’s child nodes have been eliminated, then that node will also be eliminated. We can thus “backtrack” to the next most recent possible parent node and continue our DFS from there.

Solving the problem

Now, we encode our constraints and apply DFS. One final wrinkle is deciding a value for \(k\). Remember that after move 18, the knight begins recording its score every \(k\) moves for some \(k>3\). That can be solved by picking some \(k\), running the DFS, and seeing if it creates a constraint-satisfying path. That only works with \(k=7\).

Once you have this path, just add up the scores on the tiles adjacent to the unvisited tiles to find the answer.

Binary disease tests are used to estimate disease prevalence in a population. When test kits are scarce, researchers and epidemiologists may choose to test samples pooled from multiple people. Further, with observational studies and meta-analyses, you may end up with results from both individual and pooled samples. To combine these results into a single estimate of the population prevalence, some prior work leapt to using compute-heavy and slow MCMC methods. We (Charles Copley, my colleague from Ancera, and I) found a closed-form posterior distribution for the population prevalence that can be computed in a fraction of a second. This post is an overview of that work. The full derivation + analysis is on arXiv.

Why pool samples at all?

Let’s say we are trying to measure a population prevalence \(p\). If you were to sample \(n\) individuals, then you would see about \(np\) positives. Now, what if \(p=.01\)? Well you would need to sample 100 individuals to see on average 1 positive result. We can boost that signal by pooling.

The probability of a pooled sample testing positive when \(q\) individuals are pooled, \(\pi _q\), is equivalent to the probability that at least one of the samples which are combined into the pooled sample is positive. We’ll assume that each individual’s positivity is i.i.d. Bernoulli.

Or, if you want to see it visually:

Let’s quantify the difference in information a single individual test yields vs. a single pooled test.

Say \(X\) is a Bernoulli random variable representing the result of an individual test. Its likelihood function over possible outcomes \(k\) is

Say \(Y\) is a Bernoulli random variable representing the result of a pooled test. Its likelihood function over possible outcomes \(k\) is

Fisher information \(I(p)\) is calculated as the negative expected value of the second derivative of the log-likelihood. It measures how much reads of a RV tell us about an unknown parameter of its distribution.

For the individual test,

For the pooled test (thank you Wolfram Alpha),

so

Notice that our \(q=1\) case matches \(I_X (p)\). So, the information ratio between these is

The ratio approaches \(q\) as \(p\rightarrow0\), meaning that at low prevalences a pooled test of \(q\) samples is up to \(q\) times as informative as an individual sample, meaning that you can get the same info for about \(q\) times as few samples.

Fusing information from pooled and individual tests

Define \(P\) as a random variable for population prevalence. We will use \(p\) to denote outcome values of that random variable.

Define \(m\) as the number of individual tests conducted.

Define \(Y_1,Y_2,...Y_m\) as random variables for the binary results of these individual tests.

Define \(y\) as the number of observed positive individual tests.

Define \(n\) as the number of pooled tests conducted.

Define \(Z_1,Z_2,...Z_n\) as random variables for the binary results of these pooled tests.

Define \(z\) as the number of observed positive pooled tests.

As before, we’ll use \(\pi_q\) for the probability of a pooled sample testing positive when \(q\) individuals are pooled.

In general, we assume a beta prior distribution for \(P\) \(P \sim Beta(\alpha, \beta)\) so

where \(B(\alpha, \beta)\) is the beta function of \(\alpha\) and \(\beta\).

Bayes’ Theorem can be stated for this problem as

At this point, the prior work plugged these equations into an MCMC solver. We will solve \(\Pr(P=p \mid Y=y, Z=z)\) analytically instead.

The closed form solution

For the full derivation, you should check out our arxiv post, but the gist is that you can use a binomial expansion of \(\pi_q^z\)

and linearity of integration to solve a closed form for the “evidence”, \(Pr(Y=y, Z=z)\). After a few pages of derivations, and substituting \( \gamma = y+\alpha \) and \( \delta = m-y+\beta+qn-qz \), we can derive the posterior distribution.

This function is exact, integrable, and evaluates way faster than a MCMC chain. Further, if you need to include sensitivity or specificity, those generalize in the same way, even if you allow them to vary along another beta distribution.

Weighted sum of betas

One cool thing about this equation is that we can rewrite it to reveal a bit of structure. The posterior is an affine combination of beta distributions!

Let \(f(p, \gamma, \delta + qi)\) be the PDF of the beta distribution with parameters \(\gamma\), and \(\delta + qi\), evaluated at \(p\).

So we can also write the posterior probability distribution for \(P\) in this form:

The widget below shows a given posterior’s weighted components and their sum. It also shows the closest-fitting single beta distribution.

The posterior distribution

Explore the posterior! Drag the sliders to set the experimental setting and see the resulting posterior. Hit resample to change the drawn data and resulting fit. You can see that pooled tests are more useful at low \(p\) and that degraded sensitivity and specificity result in a wider posterior distribution.

Budgeting fixed and pooled tests

So, practically, if you have a fixed test budget (who doesn’t) and you expect low prevalence, you should consider pooling. Our paper shows extensive simulation of the tradeoffs here, so check it out if you’re curious.

Recently, I have been enjoying solving Jane Street’s backlog of puzzles. Last night, I solved Robot Baseball from October 2025. This post is my write-up of the math I learned while solving it, so if you haven’t already, take a second to read the puzzle!

In brief, Robot Baseball is a Markov game. Its states are numbers of balls and strikes. The game ends when balls=4 or strikes=3. To find the Nash equilibria at each state, we need to first model the terminal states and then use backward induction to solve each subgame equilibrium until we have found an equilibrium for each possible state.

The catch is that if the pitcher throws a strike and the batter swings, the batter hits with probability \(p\) and misses with probability \(1 - p\). We want to optimize \(p\) to maximize our odds of reaching \((\text{balls}=3, \text{strikes}=2)\). The players’ payoffs at each step and their equilibrium strategies are therefore functions of \(p\). This is straightforward symbolically when we are calculating the equilibrium for \((\text{balls}=3, \text{strikes}=2)\), but over the many inductive steps back to the initial state of the game, those symbolic expressions blow up into an ungodly hard-to-compute-precisely large polynomials of \(p\).

The key is to realize that

1) For a given \(p\), the equilibria for the full game can be computed very quickly

2) \(\Pr(\text{balls}=3, \text{strikes}=2)\) when viewed as a function of \(p\) has a single maximum value

These two things mean that we can use a black box search algorithm like golden section search to compute the \(p\) that maximizes \(\Pr(\text{balls}=3, \text{strikes}=2)\) to arbitrary precision.

Now, let’s go through the derivations and solution in detail.

Modeling a Single-Turn Zero-Sum Game

Let’s forget everything about robot baseball for a minute and think about a very simple game.

Player 1 has a choice to select Top or Bottom. They select Top with some probability \(p\) and Bottom with probability \(1-p\).

Player 2 has a choice to select Left or Right. They select Left with some probability \(q\) and Right with probability \(1-q\).

Let’s say there are 4 outcomes possible depending on the combination of actions the players take. The players choose actions simultaneously.

Let’s say that this is a zero-sum game, meaning that for a given outcome Player 1’s gain is equivalent to Player 2’s loss. We’ll put those payoffs in terms of gains or losses for Player 1 and leave them as variables: \(a, b, c, d\). Remember that a benefit of \(a\) to Player 1 is a benefit of \(-a\) to Player 2.

We’ll also assume that both players have total knowledge of the game’s payoff matrix.

We can record this setup for the game in a payoff matrix.

Now, we want to model the expected payoffs for each player across the set of strategies they can choose to identify their optimal strategies.

For shorthand, we’ll use \(\operatorname{E}[L]\) for Player 1’s expected score if Player 2 chooses Left and \(\operatorname{E}[R]\) for Player 1’s expected score if Player 2 chooses Right.

If Player 1 picks \(p\) so that \(\operatorname{E}[L] > \operatorname{E}[R]\), Player 2 could win more by picking Right, and vice versa. To maximize their score against any opponent, including one that knows their strategy, Player 1 wants to maximize \(\min(\operatorname{E}[L], \operatorname{E}[R])\).

We can graph both expectations as functions of \(p\):

\(\min(\operatorname{E}[L], \operatorname{E}[R])\) is concave, so it will have some maximum within \([0,1]\). If that max \(\in\{0, 1\}\), then Player 1 will just always pick one of their options because it will always be better.

Otherwise, that \(\max(\min(\operatorname{E}[L], \operatorname{E}[R]))\) will occur at the intersection of \(\operatorname{E}[L] = \operatorname{E}[R]\). Therefore, Player 1 selects \(p\) to meet that condition:

You can do the same calculation for \(q\).

These strategies \(p\) and \(q\) are this game’s Nash equilibrium.

Modeling a Simultaneous-Move Markov Game

Markov games are repeated games where the players progress through game states where some or all of the progression probabilities are stochastic. Robot Baseball is a simultaneous-move Markov game.

Let’s call the game state where \(b\) is the number of balls and \(s\) is the number of strikes \((b,s)\).

Let’s call the expected value of a state of the game for the batter \(V(b,s)\). This is a zero-sum game, so the expected value for the pitcher would be \(-V(b,s)\).

We know that \(V(4,s) = 1\) and \(V(b,3) = 0\) for any values of b or s. A home run has a value of 4. These are our terminal states.

To model this game, we will need to start from these known terminal states and work backwards via induction. First, let’s set up our game’s payoff table for an arbitrary state \((b,s)\). We will put the values of the next states in terms of our function V so this can be used as a recurrence relation.

Remember from the question that we do not know \(p\), which is the probability that StrikexSwing will net a home run.

Let’s simplify our notation a bit by substituting \(X=V(b+1,s)\) and \(Y=V(b,s+1)\).

Let’s find the Nash equilibrium for this state of the game.

Rearrange to see that

and we can see by the symmetry of the payoff matrix that \(r = q\).

So, we can find a general form for \(V(b,s)\):

Which is a recurrence relation that can combine this with our boundary values \(V(4,s) = 1\) and \(V(b,3) = 0\) to calculate any \(V(b,s)\). This process is called Backward Induction.

Calculating \(V(b,s)\) symbolically yields a a rational function in \(p\) with degree-49 numerator and denominator with huge coefficients, but luckily we don’t need to do that. Calculating the full table of values for \(V(b,s)\) given some value for \(p\) can be done very quickly, which will be enough for us.

Now, since we know \(q\) and \(r\) at each possible state of the game, we can calculate transition probabilities between states. Remember that \(q\)=\(r\)

At state \((b,s)\):

We want to maximize our odds of getting to \((3,2)\).

Call \(R(b,s)\) the probability of reaching \((3,2)\) from \((b,s)\).

From reading off our transition table, we can see that

I’ve skipped it here to simplify notation, but remember that \(q\) is itself a function of \((b,s)\). So, we have another recurrence relation that we can combine with our recurrence relation for \(V(b,s)\) to calculate \(R(0,0)\). \(R(0,0)\) is another insane rational function of \(p\), but luckily again, we won’t need to use that symbolic form. Given some \(p\), we can quickly calculate \(R(0,0)\).

Visualizing the Value and Reach Probability as Functions of p

Before we move on to solving, I wanted to show off these curves!

Look at that clean maximum for \(R(0,0)\)!

Black Box Search and Solving the Puzzle

Now we can calculate \(R(0,0)\) quickly for any value of \(p\) and can see in the plot above that \(R(0,0)\) has a clear single maximum in \([0,1]\). We can adapt Descartes’ Rule of Signs to rigorously prove that \(R(0,0)\) has a single maximum in \([0,1]\), but I will skip that.

Let’s calculate \(\operatorname*{arg\,max}\limits_{p \in [0,1]}\ R(0,0)\).

We will use golden section search, a blackbox (derivative free) optimization technique, because maximizing \(R(0,0)\) would involve computing the derivative of an insane rational polynomial in \(p\), which would cause a slew of precision issues that we don’t need to deal with.

This runs in less than a second. Here are our solutions to 10 decimal places:

Here is the search’s trace, in case you’re curious.

What is SIWE?

Sign-in With Ethereum (SIWE) is a method for using Ethereum addresses to authenticate on off-chain services. Implementing SIWE means that your users don’t need to create a separate account on your website as long as they already have an address on Ethereum or any other EVM-compatible chain.

SIWE allows authentication on decentralized apps (dApps), where users must already have an address to transact. Authenticating with that address saves them from needing to manage separate login info.

The SIWE Method

SIWE relies on the same public-key cryptography that addresses use to transact on EVM chains. In brief:

1. The server sends a cryptographic nonce to the client. This nonce is just a one-time-use randomly generated string. This nonce will be included in the message in the next step to prevent replay attacks, where an attacker would record a user’s signed SIWE message and attempt to authenticate as that user by sending your server the same signed message.
2. The server sends a message to the client for signing. That message attests at least these fields:
   • The user’s address
   • The domain requesting the SIWE
   • SIWE message version
   • The EVM chain id that your site uses
   • The URI of the resource that will validate the SIWE message and authenticate the user
   • The nonce from step 1
   • The time that the message was issued
3. The user signs the SIWE message with their private key and sends it to the site’s login endpoint along with their address.
4. The server checks the signature to make sure that the true owner of the address sent the signed SIWE message. The server also verifies the message’s fields.

An Example SIWE Message

your-dapp.xyz wants you to sign in with your Ethereum Address:
0x105d00D5f671B236AfED1D2EEF5D7d566382E8C3

URI: your-dapp.xyz/login
Message Version: 2.1
Chain ID: 1
Nonce: 92649128
Issued At: 2025-10-04T17:00:00Z

Why would you use SIWE with Django?

Django is a commonly used Python web framework. It provides abstractions that allow you to easily create database models, set up CRUD and more complicated endpoints, and handle user permissions.

OK, so Django is a conventional web framework. But SIWE is mostly for dApps, right? Why use it with Django? Well, dApps store data on blockchains, but you may want to store some user or app data off-chain to:

1) Save gas on storage space 2) Store data types like videos that have poor support on blockchains 3) Reduce latency

If you want to create a hybrid dApp that also stores data on a centralized server, Django is a good choice because of its rapid development, ease of maintenance, and good scalability. Here are some specific hybrid dApp use cases:

• You want to allow users to customize their dApp UI and save those customizations between sessions without storing that info on-chain
• Your dApp stores compressed attestations of data on the chain to save gas, so you need a conventional backend to store full-size records
• You want users to view their transaction history without waiting for a long and complicated blockchain query

So, to create a hybrid Django dApp, you will likely want to implement SIWE in Django.

Implementing SIWE in Django

Your SIWE implementation will need three key components:

1) A SiweUser model that extends the base Django user model with an Ethereum address field 2) SIWE verification logic and an authentication backend 3) A SIWE login view

Let’s put these components into their own django app within your project.

python manage.py startapp siweauth

I did this for a project earlier this year, so you can also check out my implementation here. Note that I used JWTs instead of Django’s built-in session framework, so there will be some differences in how you manage user sessions.

The SiweUser Model

Django’s base user model has almost everything you need for basic auth and user management. We just need to add a field for the user’s Ethereum address and a manager method to create users with just an address.

We will also need a model for the SIWE message’s nonce. This nonce should be single-use and have an expiration time.

# siweauth/models.py
"""
Database models for SIWE
"""

from django.db import models
from django.core.validators import RegexValidator
from django.core.exceptions import ValidationError
from django.contrib.auth.models import BaseUserManager, AbstractBaseUser
from web3 import Web3


def validate_ethereum_address(value):
    """
    Validate that an Ethereum address is correctly checksummed.
    
    Args:
        value: The Ethereum address to validate
        
    Raises:
        ValidationError: If the address is not a valid checksummed Ethereum address
    """
    if not Web3.isChecksumAddress(value):
        raise ValidationError


class Nonce(models.Model):
    """
    A temporary nonce used for SIWE authentication.
    
    Nonces are single-use random values that prevent replay attacks during
    authentication and have expiration times.
    """
    value = models.CharField(max_length=24, primary_key=True)
    expiration = models.DateTimeField()

    def __str__(self):
        return self.value


class SiweUserManager(BaseUserManager):
    """
    Manager for the custom SiweUser model.
    
    This manager provides methods for creating users authenticated via SIWE
    """
    def create_user_address(self, address):
        """
        Create and save a SiweUser with the given Ethereum address.
        
        Args:   
            address: The Ethereum wallet address
            
        Returns:
            SiweUser: The created user instance
            
        Raises:
            ValueError: If no address is provided
        """
        if not address:
            raise ValueError("SiweUsers must have an eth address")
        validate_ethereum_address(address)
        user = self.model(
            wallet=address,
        )
        user.save(using=self._db)
        return user


class SiweUser(AbstractBaseUser):
    """
    This model extends AbstractBaseUser to support authentication via SIWE.
    """
    wallet = models.CharField(
        verbose_name="Wallet Address",
        max_length=42,
        unique=True,
        primary_key=True,
        validators=[
            RegexValidator(regex=r"^0x[a-fA-F0-9]{40}$"),
            validate_ethereum_address,
        ],
    )
    username = models.CharField(max_length=150, blank=True, null=True, unique=True)
    email = models.CharField(max_length=150, blank=True, null=True, unique=True)
    is_admin = models.BooleanField(default=False)
    is_staff = models.BooleanField(default=False)
    password = models.CharField(max_length=128, blank=True)
    objects = SiweUserManager()

    USERNAME_FIELD = "wallet"
    REQUIRED_FIELDS = []

    def __str__(self):
        return self.wallet

    @property
    def is_superuser(self):
        return self.is_admin

    def has_perm(self, perm, obj=None):
        return self.is_admin

    def has_module_perms(self, app_label):
        return self.is_admin

Now, register the custom user model in your settings.py file.

# your_project/settings.py
...
AUTH_USER_MODEL = "siweauth.SiweUser"
...

SIWE Verification and Authentication

We will write custom authentication methods to verify SIWE methods and allow authentication by Ethereum address.

SIWE Verification

First, let’s create some settings for those SIWE message fields. Our validation will check that the messages’ fields match these expected values. These settings are hardcoded so you can see them, but you should set yours in environment variables for security.

# your_project/settings.py
...
# SIWE message validity window in minutes
SIWE_MESSAGE_VALIDITY = 5  # 5 minutes
# Expected chain ID for SIWE messages
SIWE_CHAIN_ID = 11155111 # Ethereum sepolia testnet
# Expected domain for SIWE messages
SIWE_DOMAIN = "your-dapp.xyz"
# Expected URI for SIWE messages
SIWE_URI = "https://your-dapp.xyz/login"
...

Now, we need to write some functions to verify SIWE messages using those settings.

• _nonce_is_valid ensures that our SIWE messages’ nonces are valid.
• parse_siwe_message splits our plaintext SIWE messages into fields for validation.
• check_siwe validates those fields.

# siweauth/auth.py
import datetime, pytz
from web3 import Web3
from hexbytes import HexBytes
from eth_account.messages import encode_defunct
import re
from your_project.settings import (
    SIWE_MESSAGE_VALIDITY,
    SIWE_CHAIN_ID,
    SIWE_DOMAIN,
    SIWE_URI,
)
from siweauth.models import Nonce

w3 = Web3()


def _nonce_is_valid(nonce: str) -> bool:
    """
    Check if given nonce exists and has not yet expired.
    :param nonce: The nonce string to validate.
    :return: True if valid else False.
    """
    n = Nonce.objects.filter(value=nonce).first()
    is_valid = False
    if n is not None:
        if n.expiration > datetime.datetime.now(tz=pytz.UTC):
            is_valid = True
            n.delete()
    return is_valid


def parse_siwe_message(message_body: str) -> dict:
    """
    Parse SIWE message into components.
    Returns a dict or None if parsing fails.
    """
    try:
        domain_match = re.match(r"^([^\s]+) wants you to sign in with your Ethereum Address:", message_body)
        address_match = re.search(r"Ethereum Address:\n(0x[a-fA-F0-9]{40})", message_body)
        uri_match = re.search(r"^URI:\s*(.+)$", message_body, re.MULTILINE)
        version_match = re.search(r"^Message Version:\s*(.+)$", message_body, re.MULTILINE)
        chain_id_match = re.search(r"^Chain ID:\s*(\d+)$", message_body, re.MULTILINE)
        nonce_match = re.search(r"^Nonce:\s*(.+)$", message_body, re.MULTILINE)
        issued_at_match = re.search(r"^Issued At:\s*(.+)$", message_body, re.MULTILINE)

        if not (domain_match and address_match and uri_match and version_match and chain_id_match and nonce_match and issued_at_match):
            return None

        domain = domain_match.group(1).strip()
        address = address_match.group(1).strip()
        uri = uri_match.group(1).strip()
        version = version_match.group(1).strip()
        chain_id = int(chain_id_match.group(1))
        nonce = nonce_match.group(1).strip()
        issued_at = datetime.datetime.fromisoformat(issued_at_match.group(1).strip())

        return {
            "domain": domain,
            "address": address,
            "uri": uri,
            "version": version,
            "chain_id": chain_id,
            "nonce": nonce,
            "issued_at": issued_at,
        }
    except Exception as e:
        # Optionally log the error here
        return None


def check_siwe(message, signed_message):
    # check for format
    if type(message) != str:
        body = str(message.decode())
    else:
        body = message
    # Parse message components
    parsed = parse_siwe_message(body)
    if not parsed:
        return None
    # Validate timestamp
    now = datetime.datetime.now(parsed["issued_at"].tzinfo)
    if abs((now - parsed["issued_at"]).total_seconds()) > SIWE_MESSAGE_VALIDITY * 60:
        return None

    # Validate chain ID
    if parsed["chain_id"] != SIWE_CHAIN_ID:
        return None

    # Validate domain and URI
    if parsed["domain"] != SIWE_DOMAIN or parsed["uri"] != SIWE_URI:
        return None

    # check for nonce in db
    if not _nonce_is_valid(parsed["nonce"]):
        return None
    # recover address from nonce / signed message
    address = parsed["address"]
    try:
        recovered_address = w3.eth.account.recover_message(
            signable_message=encode_defunct(text=body),
            signature=HexBytes(signed_message),
        )
    except:
        return None
    # make sure recovered address is correct
    if address != recovered_address:
        return None
    return recovered_address

SIWE Authentication

A Django authentication backend is a class that implements two methods, authenticate and get_user. Let’s write a custom authentication backend that uses our verification methods to implement those methods with SIWE.

# siweauth/backend.py

from django.contrib.auth.backends import BaseBackend
from web3 import Web3
from eth_account.messages import SignableMessage
import logging

from siweauth.models import SiweUser
from siweauth.auth import check_siwe

w3 = Web3()

class SiweBackend(BaseBackend):
    """
    Authentication backend for Sign-In with Ethereum.
    """

    def authenticate(
        self, request, message: SignableMessage = None, signed_message=None
    ):
        """
        Authenticate a user with SIWE
        
        Args:
            request: The HTTP request
            message: The SIWE message
            signed_message: The signature of the message
            
        Returns:
            SiweUser: The authenticated user, or None if authentication fails
            
        Note:
            Creates a new user if one doesn't exist for the recovered address
        """
        # request must have message and signed_message fields
        if None in [message, signed_message]:
            return None
        recovered_address = check_siwe(message, signed_message)
        if recovered_address is None:
            return None
        # if user exists, return user
        user = SiweUser.objects.filter(wallet=recovered_address).first()
        # if user doesn't exist, make a user for this wallet
        if user is None:
            user = SiweUser.objects.create_user_address(recovered_address)
        return user

    def get_user(self, user_address):
        """
        Retrieve a user by user address.
        
        Args:
            user_address: The address of the user to retrieve
            
        Returns:
            SiweUser: The user with the given address, or None if not found
        """
        try:
            return SiweUser.objects.get(pk=user_address)
        except SiweUser.DoesNotExist:
            return None

Now, register SiweBackend in your settings.py file.

# your_project/settings.py
...
AUTHENTICATION_BACKENDS = [
    'siweauth.backend.SiweBackend',
    ...
]
...

SIWE Views

Let’s write a view that the front end can call to get a nonce.

# siweauth/views.py

import datetime
import pytz
import secrets
from django.http import JsonResponse
from django.views.decorators.http import require_http_methods
from siweauth.models import Nonce


@require_http_methods(["GET"])
def get_nonce(request):
    """
    Generate and return a new nonce for SIWE authentication.
    """
    now = datetime.datetime.now(tz=pytz.UTC)

    for n in Nonce.objects.filter(expiration__lte=datetime.datetime.now(tz=pytz.UTC)):
        n.delete()
    n = Nonce(value=secrets.token_hex(12), expiration=now + datetime.timedelta(hours=3))
    n.save()

    return JsonResponse({"nonce": n.value})

Here’s an example request to this view:

GET /api/auth/nonce/ HTTP/1.1
Host: your-dapp.xyz

Finally, we need a view that will handle SIWE login requests. This view will call our custom SIWE authentication backend and log the user in if they pass our SIWE verification. Here is a super simple view for this purpose:

# siweauth/views.py
from django.contrib.auth import login
from your_siwe_package import authenticate

def siwe_login_view(request):
    """Handle SIWE login requests."""
    message = request.POST.get("message")
    signed_message = request.POST.get("signature")
    # This calls your SIWE authentication backend
    user = authenticate(message=message, signed_message=signed_message)
    if user is not None:
        login(request, user)  # This creates a session and sets the sessionid cookie
        return JsonResponse({"success": True})
    else:
        return JsonResponse({"success": False}, status=401)

Here’s an example request to this view:

POST /login HTTP/1.1
Host: your-dapp.xyz
Content-Type: application/x-www-form-urlencoded
message=your_siwe_message&signature=0xYourSignature

where your_siwe_message is the plaintext SIWE message, and 0xYourSignature is the signature of that message.

Testing your implementation

Testing your SIWE implementation is essential for maintaining security. To get some ideas for tests, check out my implementation’s siweauth tests. In general, you will need to

• Test your Nonce model functions
• Test your SIWE message parsing and verification methods
• Test your views for getting nonces and for submitting SIWE messages

Conclusion

Rig up your frontend to use these login views and you will be off to the races with your hybrid dApp. Your users will be able to log in with Ethereum and use your app without breaking their decentralized flow, but you will still be able to track user info with a performant and scalable centralized database.

When you’re ready to put your hybrid dApp on the internet, my Web Dev for Dirtbags series covers deploying a Django + React app on your own server, and Part 3 covers hardening that server.

• Purpose: security
• Prerequisites
• Lock down access
  • ssh keys
  • Firewall
  • Blacklisting and Fail2ban
• Keep your installs fresh
  • System packages
  • npm
  • Python venv
• Restrict custom systemd services and Nginx
  • Restricting systemd services’ permissions
  • Add systemd security options
  • Configure Nginx for security

This is Part 3 of the Web Dev for Dirtbags series. Start with Part 1: Basics and Static Sites and Part 2: Deploying a Django + React Web App.

Purpose: security

You should take a few simple steps to harden your web server’s security. In this guide, I will show you how to:

1. Lock down access with ssh keys, a firewall, and fail2ban for banning vulnerability scanners
2. Enable unattended upgrades to prevent fresh exploits
3. Restrict permissions for systemd services and Nginx

These instructions are for Ubuntu/Debian-based systems. This probably applies to your cheap VPS, but you should make sure.

Prerequisites

I will also assume that you have a web server set up and ready to serve a website. If you don’t have these set up yet, I recommend reading and following my previous posts on serving static and dynamic sites.

Lock down access

Your server and your users’ data can be accessed directly through ssh or indirectly through the pages that you are serving over its ports. Let’s close some of those openings.

ssh keys

To start, let’s make sure that your server can only be accessed through ssh keys. ssh keys are more secure than username and password logins because they are much harder to brute force or guess. Additionally, they are not transmitted across the network to your remote VPS, so your password cannot be intercepted during transmission.

To set up ssh key access to your remote machine:

1. On your local machine, run ssh-keygen -t ed25519 to generate a new key pair with the ed25519 algorithm. Set up a passphrase when prompted for extra security.
2. Copy the public key that you just generated, by default id_ed25519.pub, over to the ~/.ssh/authorized_keys folder on your VPS:

   cat ~/.ssh/id_ed25519.pub | ssh username@your-vps-ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
   

   Replace username with your VPS username and your-vps-ip with your server’s IP address. If you don’t have ssh access, create this file and add the public key manually via your VPS provider’s control panel.

3. Add the private key to your ssh agent:

   eval "$(ssh-agent -s)" # for linux and mac. for windows use ssh-agent -s
   ssh-add ~/.ssh/id_ed25519 # or whatever file name you gave your private key
   

4. Test your ssh key authentication by running:

   ssh username@your-vps-ip
   

   If you were able to log in without your password, then this worked!

ONLY ONCE YOU CONFIRM THAT YOU CAN SSH IN WITH THE KEY, you can disable password authentication:

1. On your remote machine, modify /etc/ssh/sshd_config to include this line:

   PasswordAuthentication no
   

2. Restart the SSH service:

   sudo systemctl restart ssh
   

   If everything is set up correctly, you should be able to log in without being prompted for a password.

Firewall

A firewall is a service that filters and blocks connections based on predefined rules. Uncomplicated Firewall, or ufw, is a simple and user-friendly interface for defining a firewall.

To set up ufw on your VPS:

1. Make sure you have ssh access to your server. Follow the previous section if you don’t. Log in using your SSH key.
2. Install ufw if it’s not already installed:

   sudo apt-get install ufw
   

3. Allow SSH connections and HTTP/HTTPS traffic:

   sudo ufw allow ssh
   sudo ufw allow http
   sudo ufw allow https
   

4. Enable the firewall:

   sudo ufw enable
   

5. Check the status of the firewall:

   sudo ufw status
   

Blacklisting and Fail2ban

Automated vulnerability-finders are constantly scanning open ports for accidentally exposed files. If you check the access logs for your site, you will probably see loads of failed requests looking for seemingly random .php, .xml, .env, or other sensitive files. Here’s an example log trace from my website.

20.196.80.178 - - [03/Sep/2025:16:14:41 +0000] "GET /dfre.php HTTP/1.1" 404 162 "-" "-"
20.196.80.178 - - [03/Sep/2025:16:14:42 +0000] "GET /disagimons.php HTTP/1.1" 404 162 "-" "-"
20.196.80.178 - - [03/Sep/2025:16:14:42 +0000] "GET /disagreop.php HTTP/1.1" 404 162 "-" "-"
20.196.80.178 - - [03/Sep/2025:16:14:43 +0000] "GET /manager.php HTTP/1.1" 404 162 "-" "-"
20.196.80.178 - - [03/Sep/2025:16:14:43 +0000] "GET /uploan.php HTTP/1.1" 404 162 "-" "-"
104.248.157.27 - - [03/Sep/2025:16:35:29 +0000] "GET //wp-includes/wlwmanifest.xml HTTP/1.1" 404 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
104.248.157.27 - - [03/Sep/2025:16:35:29 +0000] "GET //xmlrpc.php?rsd HTTP/1.1" 404 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
104.248.157.27 - - [03/Sep/2025:16:35:29 +0000] "GET //blog/wp-includes/wlwmanifest.xml HTTP/1.1" 404 564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

This shows automated scanning from two separate source IP addresses. Notice that each of these requests are returned 404 not found errors.

Fail2ban is a service that monitors requests to your page for suspicious activity. It can automatically block IP addresses that show malicious signs, such as too many password failures or seeking for exploits like those shown in the log.

To set up Fail2ban on your VPS:

1. Install Fail2ban:

   sudo apt-get install fail2ban
   

2. Configure Fail2ban to block repeated failed requestors:

   sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
   sudo nano /etc/fail2ban/jail.local
   

   Within the [DEFAULT] section, set these values:

   bantime = 1h
   findtime = 1h
   maxretry = 5
   

3. Start the Fail2ban service:

   sudo systemctl start fail2ban
   

4. Enable Fail2ban to start on boot:

   sudo systemctl enable fail2ban
   

Keep your installs fresh

Another key aspect of server security is to stay on top of updates for your dependencies and server software.

System packages

To update your system packages, use the following commands:

sudo apt-get update
sudo apt-get upgrade

To set up automatic updates, you can install and enable the unattended-upgrades package, which automatically installs security updates:

sudo apt-get install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

npm

For Node.js applications, you can update your npm packages with:

npm update

There are packages for conducting automatic updates for npm, but it’s simpler to set a cron job to execute npm update at your desired frequency.

nano /etc/cron.daily/npm-update.sh

Copy this into nano /etc/cron.daily/npm-update.sh:

#!/bin/bash
cd /path/to/your/nodejs/app
npm update

And give the cron job execute permissions:

chmod +x /etc/cron.daily/npm-update.sh

Python venv

For Python applications, you can update your virtual environment packages with:

source /path/to/your/venv/bin/activate
pip install --upgrade pip
pip list --outdated | awk 'NR>2 {print $1}' | xargs -n1 pip install -U
deactivate

You can also set a cron job to automate this process.

nano /etc/cron.daily/venv-update.sh

Copy this into nano /etc/cron.daily/venv-update.sh:

#!/bin/bash
source /path/to/your/venv/bin/activate
pip install --upgrade pip
pip list --outdated | awk 'NR>2 {print $1}' | xargs -n1 pip install -U
deactivate

And give the cron job execute permissions:

chmod +x /etc/cron.daily/venv-update.sh

Restrict custom systemd services and Nginx

Your systemd services and your Nginx configuration should be set up to use the minimal permissions necessary to function. This means:

1. Running services with unprivileged users and groups
2. Add systemd security options to each service
3. Configure nginx to also use the same restricted user and group as your systemd services

You can run systemd-analyze security on your server to see a list of services and their vulnerability levels. To address these vulnerabilities, you must restrict each service in this list.

Run systemd-analyze security servicename to see detailed information for each service.

Restricting systemd services’ permissions

1. Edit your systemd service file (something like /etc/systemd/system/yoursite.service) to contain user and group definitions for some unprivileged group. We will use www-data for both.

   # filepath: /etc/systemd/system/yoursite.service
   # ...existing code...
   [Service]
   User=www-data
   Group=www-data
   # ...existing code...
   

2. Restrict file permissions for the files the service accesses. For example, if your service accesses files in /var/www/yoursite/servicefolder, you can run:

   sudo chown -R www-data:www-data /var/www/yoursite/servicefolder # change ownership to our user and group
   sudo chmod -R 755 /var/www/yoursite/servicefolder # grants owner rwx, group rx, others rx
   

3. Restart the service to apply the changes:

   sudo systemctl daemon-reload
   sudo systemctl restart yoursite
   

Add systemd security options

Add some extra protection to your service by restricting its capabilities. Do this for each service you use.

1. Edit your systemd service file (something like /etc/systemd/system/yoursite.service) to enable security options under the [SERVICE] header. For example:

   # filename: /etc/systemd/system/yoursite.service
   [Service]
   PrivateNetwork=yes # make this service only accessible to internal network requests. Only use if Nginx is also configured to use this socket
   PrivateTmp=yes # create a private /tmp for this service
   ProtectHome=yes # prevent access to /home, /root, and /run/user 
   NoNewPrivileges=true # prevent privilege escalation
   ProtectSystem=full # make /usr read-only
   ProtectKernelModules=yes # prevent loading kernel modules
   

2. Restart the service to apply the changes:

   sudo systemctl daemon-reload
   sudo systemctl restart yoursite
   

Configure Nginx for security

Nginx starts as root so that it can access all of your server’s files, such as SSL certs. However, you should ensure that it is configured to drop to a user with lower privileges after it starts up. We will do this with user directive in your Nginx configuration file, usually located at /etc/nginx/nginx.conf.

Make sure that the user is set to a lower privileged user, such as www-data from before:

# filename: /etc/nginx/nginx.conf
user www-data;

Nginx by default emits its version on error pages and in the “Server” response header field. To disable this, add the following line to your Nginx configuration file:

# filename: /etc/nginx/nginx.conf
server_tokens off;

Some HTTP methods may be used to exploit vulnerabilities. For instance, PUT can be used to replace your server files with malicious ones. We can restrict Nginx to only allow certain HTTP methods. For instance, if your app only needs to support GET and POST, you can restrict Nginx to those with this:

# filename: /etc/nginx/nginx.conf
server {
    location / {
        limit_except GET POST {
            deny all;
        }
    }
}

You can also add these restrictions to your site’s specific Nginx configuration, locatated somewhere like /etc/nginx/sites-available/your-site.conf. The above modifications apply to all Nginx instances running on your server.

Part 2 of the Web Dev for Dirtbags series. Start with Part 1: Basics and Static Sites. Next, lock things down with Part 3: VPS Security.

Purpose: hosting a dynamic app

We are going to get you off of localhost.

1. Learn to host a dynamic web app under your own domain name on your own server
2. Gain web deployment skills:
   • Configuring a web server (Nginx) for serving a front end and a back end on the same server
   • Managing application processes (e.g., using Gunicorn)

Dynamic web pages

Dynamic web pages or apps are interactive and will change based on user input or database state.

The “front end” of a dynamic web app is the process responsible for generating and updating the user interface. It does this by communicating with the “back end” of the web app, which manages data storage and business logic while responding to the front end’s requests.

This guide will show you how to host a dynamic web page. We will use the tried and true Django back-end framework and the ubiquitous React front-end framework as concrete examples, but we will also discuss general principles that apply to the myriad other web dev frameworks.

Prerequisites

For the rest of this guide, I will assume that you have basic Django and React applications set up and running locally. Follow those links for the official tutorials if you need help getting started.

I will also assume that you have a Virtual Private Server (VPS) set up and ready to go and a domain name purchased and pointed at your VPS. If you don’t have these set up yet, I recommend reading and following my previous post on setting up a VPS and domain name for hosting static sites.

Configuring Django

1. Set up a Python virtual environment
2. Namespace all your back end’s urls
3. Update your settings.py so your back end can serve requests from your front end
4. Configure Gunicorn, your Web Server Gateway Interface (WSGI)

Python environment

Python comes stock with venv, a module for creating lightweight virtual environments. You are running this on a resource-constrained (cheap) VPS, so you should keep your venv lean.

From your dev environment, create a requirements.txt file by running pip freeze > requirements.txt. Copy this to your server and create a venv there with:

python3 -m venv yourvenv
source yourvenv/bin/activate
pip install -r requirements.txt

Namespacing

You should namespace all of your back end endpoints with some common prefix so they don’t clash with your front end’s urls (e.g., /api/v1/whatever).

Later, this will allow us to route front-end requests and back-end requests to separate processes more easily.

settings.py

Because your back end and front end are separate processes and will have their own origins, you will need to configure a few things in your settings.py so your back end can serve requests from your front end. If you do not do these things, then your back end cannot answer requests from your front end.

Cross-site request forgery (CSRF) is an exploit where a site’s browser is tricked into sending a request to a different site. This can cause the user to unwittingly submit forms on some other site (like their bank) or expose user information. To prevent this, browsers block cross-origin requests by default. However, because your front end and back end are on different origins, you will need to explicitly allow requests from your front end to your back end.

Cross-origin resource sharing (CORS) is a feature that permits browsers to make limited cross-origin requests. To enable your cross-origin requests, do the following:

1. In your server’s python environment, install the django-cors-headers package:

   pip install django-cors-headers
   

2. Add corsheaders to your INSTALLED_APPS in settings.py:

   INSTALLED_APPS = [
    # ...existing code...
    'corsheaders',
    # ...existing code...
   ]
   

3. Add the CorsMiddleware to your MIDDLEWARE in settings.py, making sure it’s placed above CommonMiddleware:

   MIDDLEWARE = [
    # ...existing code...
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    # ...existing code...
   ]
   

4. Specify the allowed origins in settings.py:

   CORS_ALLOWED_ORIGINS = [
    "https://your_domain.com",
    "http://localhost:3000", # for local development
   ]
   

5. Configure CSRF settings in settings.py:

   CSRF_TRUSTED_ORIGINS = [
    "https://your_domain.com",
    "http://localhost:3000", # for local development
   ]
   

To allow your server to be hosted on your domain, add the following to settings.py:

ALLOWED_HOSTS = [
    "your_domain.com",
    "localhost", # for local development
]

Django’s secret key is used for cryptographic signing. You should set it in a .env file and load it in settings.py. We will tell Gunicorn which .env file to use in the next section.

Gunicorn

Gunicorn is a popular HTTP server for Python applications such as those built with Django or Flask. It receives HTTP requests from clients, forwards them to the Python process running your app, and forwards the Python app’s response to the the client. It can respond to multiple requests concurrently.

Install it with pip install gunicorn.

Make sure that all project files are owned by the user that will run the Gunicorn process (usually www-data on Ubuntu). You can change the ownership with:

sudo chown -R www-data:www-data /var/www/yourproject

Test it with:

gunicorn your_project.wsgi:application

But, this is not how you should run Gunicorn on your server. Instead, you should use a service that will spin up Gunicorn when it is needed to serve a request and manage the process for you. systemd is the best choice for this.

To configure systemd to manage your Gunicorn process, we will create two files. systemd.service files define how the service will be controlled. systemd.socket files define how the service will be started.

1. Create a systemd.socket file for Gunicorn:

   # filepath: /etc/systemd/system/yoursite.socket
   [Unit]
   Description=gunicorn socket
   # Direct Gunicorn requests to this socket file
   [Socket]
   ListenStream=/run/yoursite.sock 
   # Create this socket on boot
   [Install]
   WantedBy=sockets.target 
   

   Make sure to replace yoursite with the actual name of your project.

2. Create a systemd.service file for Gunicorn:

   # filepath: /etc/systemd/system/yoursite.service
   [Unit]
   Description=gunicorn daemon
   # Require the file we created in step 1
   Requires=yoursite.socket 
   After=network.target
   [Service]
   # Allow this service to access back end files
   User=www-data
   Group=www-data
   # Set base folder to the one that contains your Django project
   WorkingDirectory=/var/www 
   # 
   ExecStart=/var/www/your-venv/bin/gunicorn \
          --access-logfile - \ # log to stdout
          --workers 3 \ # number of worker processes
          --bind unix:/run/yoursite.sock \ # This is the socket file from step 1 defined with ListenStream
          --access-logfile /var/log/gunicorn/yoursite.access.log \
          --error-logfile /var/log/gunicorn/yoursite.error.log \
          yoursite.wsgi:application
   # If you have environment variables
   EnvironmentFile=/var/www/yoursite/.env 
   [Install]
   WantedBy=multi-user.target
   

   Make sure to replace yoursite with the actual name of your project, set your correct WorkingDirectory and EnvironmentFile, and pass the correct virtual environment path in ExecStart.

3. Start and test your new Gunicorn service:

   sudo systemctl start yoursite.socket
   sudo systemctl enable yoursite.socket
   sudo systemctl status yoursite.socket
   

   You should see something like this:

   ● yoursite.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/yoursite.socket; enabled; preset: enabled)
     Active: active (running) since Tue 2025-09-02 22:12:07 UTC; 7s ago
   Triggers: ● yoursite.service
     Listen: /run/yoursite.sock (Stream)
     CGroup: /system.slice/yoursite.socket
   

4. Make sure you created the socket file

   file /run/yoursite.sock
   

   You should see something like this:

   /run/yoursite.sock: socket
   

5. If you see errors or if one of those prints looks wrong, try reading the logs

   sudo journalctl -u yoursite.socket
   

6. To test the whole setup, try accessing an api endpoint with curl

   curl --no-buffer -XGET --unix-socket /run/yoursite.sock localhost/api/endpoint/
   

   and you should see the HTTP response from your endpoint.

Configuring a React app for deployment

1. Install your dependencies and build your front-end app
2. Build your app

npm install

Your resource-constrained VPS will have very little RAM, so you need to keep your environment lean. This is where the super-cheap VPS approach can easily fail. Luckily, we can use the --production flag to skip dev dependencies:

npm install --production

If you see weird errors or if this run takes a very long time, you are probably coming up against your VPS’s RAM constraints.

We can get around this by using swap. Swap is disk memory that you can use to emulate RAM. Accessing swap is of course slower than accessing real RAM, but if you only need it for this one-time install, users will never see a slowdown from it.

Alternatively, install and build your app on your local machine and then transfer the build artifacts to your VPS.

npm run build

Once your dependencies are installed, you can build your React app:

npm run build

This will create a build directory containing your compiled web app’s files. If you are building on your local machine, just transfer the build directory to your VPS:

zip -r build.zip /path/to/your/build # create a zip archive of your site
scp build.zip username@vps_ip_address:/var/www/yoursite # copy the zip file to the VPS

Configuring Nginx

Reverse proxies are intermediate servers that route client requests to the appropriate backend server. We will use Nginx as a reverse proxy to either forward user requests to the Gunicorn socket or serve the React app’s static files.

1. If you don’t already have it, install Nginx on your VPS:

   sudo apt update
   sudo apt install nginx
   

2. Create a new Nginx configuration file for your website:

   sudo nano /etc/nginx/sites-available/yoursite
   

3. Add the following configuration to the file:

   # Each server block defines a virtual server's routing behavior
   # This server handles HTTP requests by redirecting them to HTTPS
   server {
    # HTTP connections come in on port 80
    listen 80;
    server_name your_domain.com www.your_domain.com;
    # Redirect those HTTP requests to HTTPS
    return 301 https://$host$request_uri;
   }
   # This server handles HTTPS requests
   server {
    # HTTPS connections come in on port 443
    listen 443 ssl;
    server_name your_domain.com www.your_domain.com;
    # SSL certificate files - tell Nginx where to find proof that the domain is yours
    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
    # Set logs
    access_log /var/log/nginx/yoursite.access.log;
    error_log /var/log/nginx/yoursite.error.log;
    # Root directory for the website: tells Nginx where to find the files to serve
    root /var/www/yoursite;
    # Default file to serve
    index index.html;
    # This location block forwards API requests to your Gunicorn process
    location /api/ {
        include proxy_params;
        proxy_pass         http://unix:/run/yoursite.sock;
    }
    # All other requests will be served with static files
    # This makes any file in /var/www/yoursite accessible, so make sure not to expose sensitive files
    # Any file that is not found will return a 404 error
    location / {
        try_files $uri $uri/ =404;
    }
   }
   

   Replace your_domain.com with your actual domain and set the correct paths to your SSL certificate files.
   Make sure not to expose sensitive files in your web root directory!

4. Enable the new site configuration:

   sudo ln -s /etc/nginx/sites-available/yoursite /etc/nginx/sites-enabled/
   

   This creates a symbolic link between your site’s configuration file in sites-available and the sites-enabled directory, which Nginx uses to determine which sites to serve.

5. Test the Nginx configuration for syntax errors and fix any errors reported in the output:

   sudo nginx -t
   

6. If the test is successful, reload Nginx:

   sudo systemctl reload nginx
   

Monitoring

We set up logging for both Nginx and Gunicorn to monitor the requests they are serving and any errors that pop up.

1. Nginx Logs: We configured access and error logs in the Nginx configuration file:

    # ...
    # Set logs
    access_log /var/log/nginx/yoursite.access.log;
    error_log /var/log/nginx/yoursite.error.log;
    # ...
   

2. Gunicorn Logs: We can also configured Gunicorn to log to a file with the --access-logfile and --error-logfile options in the systemd.service file:

    # ...
    --access-logfile /var/log/gunicorn/yoursite.access.log
    --error-logfile /var/log/gunicorn/yoursite.error.log
    # ...
   

You can access these logs with either cat or tail. For instance:

# View the last 100 lines of the access log
tail -n 100 /var/log/nginx/yoursite.access.log
# View all of the Gunicorn error log
cat /var/log/gunicorn/yoursite.error.log

Part 1 of Web Dev for Dirtbags. Next up: Part 2: Deploying a Django + React Web App and Part 3: VPS Security.

Purpose: hosting a static webpage

1. Learn to host a static webpage under your own domain name on your own server
2. Gain web deployment skills:
   • working with remote servers
   • registering a domain name and configuring your domain name service
   • simple SSL setup
   • basic Nginx configuration

Once you have learned these basics, you can move on to learning about dynamic site hosting. Let’s start simple.

Static HTML

I like simple web pages. The simplest web pages are raw, static HTML files served over the internet.

Raw files are written directly in HTML and contain all the necessary information to display a web page. Static pages do not change based on user input and will always display the same content.

Let me show you what I mean. Open a text editor and paste this text into a new file. Save it as index.html.

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>Web Dev for Dirtbags Part 1</title>
    </head>
    <body>
        Hello, Dirtbag!
    </body>
</html>

Double click that file and your browser will display a simple page. You get the idea.

There are plenty of guides out there to help you write and style nice static web pages using HTML and CSS.

A basic example

For the rest of this guide, I will assume that you have a web page with three files: index.html, page2.html, and style.css.

index.html:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>This is index.html</title>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <h1>Hello, Dirtbag!</h1>
        <p>This is a simple static web page.</p>
        <a href="page2.html">Go to Page 2</a>
    </body>
</html>

page2.html:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>This is page2.html</title>
        <link rel="stylesheet" href="style.css">
    </head>
    <body>
        <h1>Go home, Dirtbag!</h1>
        <p>This is another simple static web page.</p>
        <a href="index.html">Go back home</a>
    </body>
</html>

style.css:

body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
}
h1 {
    color: #4b2802ff;
}
p {
    color: #7b1babff;
}

Serving

Once you are happy with your page, you need to “serve” it so that others can access it as a web page. To do this, we will:

1. Register a domain name on a domain name registrar like Namecheap.
2. Rent a virtual private server (VPS) from a service like DigitalOcean.
3. Deploy your files to the VPS.
4. Make an SSL certificate for your domain.
5. Configure a web server for static file hosting. We will use Nginx for this.
6. Point your domain name to the VPS.

Register a domain name

Domain names are just human-readable addresses for your website. When you open a web browser and type in a URL, the browser uses the domain name to locate the server hosting the website and ask it for the page you want to see. Take https://www.thecleaners.ai for instance. The domain name is thecleaners.ai, and it points to a specific server on the internet.

Domain names must be registered with a domain name registrar. There are many registrars to choose from, such as Namecheap, GoDaddy, and Google Domains. Simply create an account with one of these registrars, search for a domain name that suits your page, and follow the instructions to register it. You can probably find a suitable one for less than $10.

Rent a VPS

To serve your website, you need a computer that will sit there waiting for requests from users. You could use your laptop for this, but that means that you would need to keep it on with a reliable internet connection 24/7 and expose its contents to the internet.

Instead rent a virtual private server (VPS) from a service like DigitalOcean. A VPS can easily sit there for you 24/7 and answer requests and won’t have any of your personal files on it, so this is a much better option.

While setting up your VPS, they will present you with options for your server’s resources like CPU, RAM, and storage. Your site is simple, so pick the cheapest option. Namecheap has a $4/month budget option.

Once you have set this up, note the IP address. Try to ssh (Secure Shell) into your VPS using the following command:

ssh username@vps_ip_address

Replace username with your VPS username (configure this on the provider’s dashboard) and vps_ip_address with the IP address of your VPS (find this in the provider’s dashboard). You could also set up SSH keys for passwordless login, but don’t worry about that if you don’t know what that means.

If your ssh worked, you should see a terminal prompt for your VPS. You can now run commands on your VPS as if you were sitting in front of it.

While you’re connected, go ahead and create a directory for your website files:

mkdir -p /var/www/your_website

Deploy your files

Next, to serve your website, you need to get your files to the VPS. The most common way is to use git and a remote repository on a service like GitHub (free for you, most likely). This allows you to easily update your code in the future.

However, if you don’t know what git is or if you’re a real dirtbag, you can use scp (secure copy) to copy files between your local machine and the VPS.

To use scp, open a terminal (or PowerShell on Windows) on your local machine and run the following commands:

zip -r site.zip /path/to/your/folderwithallfiles # create a zip archive of your site
scp site.zip username@vps_ip_address:/var/www/your_website # copy the zip file to the VPS

Then, ssh into the VPS:

ssh username@vps_ip_address # ssh into the VPS
ls /var/www/your_website
unzip site.zip # extract the zip file on the VPS

Replace /path/to/your/folderwithallfiles with the path to the folder with all of your site files, username with your VPS username, vps_ip_address with the IP address of your VPS, and /var/www/your_website with the VPS directory you created to hold the site files.

Set up SSL

People won’t trust your website if you are not using HTTPS. To serve your website over HTTPS, you need an SSL certificate.

The easiest way to get one is with Let’s Encrypt, which provides free SSL certificates.

1. Install Certbot on your VPS:

   sudo apt install certbot python3-certbot-nginx
   

2. Obtain an SSL certificate:

   sudo certbot --nginx -d your_domain.com -d www.your_domain.com
   

Follow the prompts to complete the certificate issuance process.

Note where the SSL certificate files are stored (usually in /etc/letsencrypt/live/your_domain.com/).

Configure Nginx for static file hosting

Now that your VPS has your website files, you need to tell it how to serve them to site visitors. We’ll use Nginx for this.

1. Install Nginx on your VPS:

   sudo apt update
   sudo apt install nginx
   

2. Create a new Nginx configuration file for your website:

   sudo nano /etc/nginx/sites-available/your_website
   

3. Add the following configuration to the file:

   # Each server block defines a virtual server's routing behavior
   # This server handles HTTP requests by redirecting them to HTTPS
   server {
    # HTTP connections come in on port 80
    listen 80;
    server_name your_domain.com www.your_domain.com;
    # Redirect those HTTP requests to HTTPS
    # 301 is a permanent redirect code
    return 301 https://$host$request_uri;
   }
   # This server handles HTTPS requests
   server {
    # HTTPS connections come in on port 443
    listen 443 ssl;
    server_name your_domain.com www.your_domain.com;
    # SSL certificate files - tell Nginx where to find proof that the domain is yours
    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
    # Root directory for the website: tells Nginx where to find the files to serve
    root /var/www/your_website;
    # Default file to serve
    index index.html;
    # Handle all other requests
    # This makes any file in /var/www/your_website accessible, so make sure not to expose sensitive files
    # Any file that is not found will return a 404 error
    location / {
        try_files $uri $uri/ =404;
    }
   }
   

   Replace your_domain.com with your actual domain and set the correct paths to your SSL certificate files.

4. Enable the new site configuration:

   sudo ln -s /etc/nginx/sites-available/your_website /etc/nginx/sites-enabled/
   

   This creates a symbolic link between your site’s configuration file in sites-available and the sites-enabled directory, which Nginx uses to determine which sites to serve.

5. Test the Nginx configuration for syntax errors and fix any errors reported in the output:

   sudo nginx -t
   

6. If the test is successful, reload Nginx:

   sudo systemctl reload nginx
   

Point your domain name to the VPS

Finally, you need to point your domain name to your VPS’s IP address.

First, on your domain name registrar’s website, Follow your registrar’s instructions for delegating nameservers to your VPS.

See your registrar’s documentation for specific instructions about nameserver. If DigitalOcean is your VPS provider, follow this guide and add the following nameservers: ns1.digitalocean.com, ns2.digitalocean.com, and ns3.digitalocean.com.

Second, on your VPS provider’s control panel, update the DNS settings for your domain to point to your VPS’s IP address. Your VPS provider should have documentation on how to do this. For DigitalOcean, see this guide.

Now, after a few minutes, your domain should point to your VPS, and you should be able to access your website using your domain name!