The Shabbat-Aware Homelab

A Question Modern Operations Manuals Do Not Answer

Every Friday afternoon, the sun moves toward the horizon, and a question
arises in my flat that no chapter of any DevOps book has ever addressed.
The homelab is running. GitLab is serving repositories, Loki is ingesting
logs, the WireGuard tunnel is keeping the LAN reachable from the outside,
the Hetzner backup script is preparing to fire at 02:00. None of these
processes care about the position of the sun. I do.

For approximately twenty-five hours, from a few minutes before sunset on
Friday until three stars are visible on Saturday evening, I observe
Shabbat. I do not perform the categories of creative work that the
Talmud calls the thirty-nine melachot. I do not deploy code. I do not
debug production. I do not write configuration. I do not, in the
ordinary sense, run a homelab.

But the homelab does not stop. It cannot stop. It hosts services that
other people use, including services that my family and friends rely on
for ordinary connectivity. It runs scheduled jobs that protect data
integrity. It alerts on conditions that, in extreme cases, could
threaten life and require pikuach nefesh response. The infrastructure
does not pause for Shabbat. The operator does.

This post is the writeup of how I have come to think about the resulting
engineering problem. It is one part halakhic argument, one part
systems-design discussion, and one part practical configuration. None of
the three parts work without the others. The intent is to be useful both
to other observant Jews who run infrastructure and to non-Jewish
engineers who are curious about how a serious religious commitment
shapes technical practice.

A note before continuing. I am not a posek. The halakhic positions I
work from are mainstream Modern Orthodox positions consistent with the
poskim I follow, but reasonable observant Jews disagree about details.
If you are reading this and your community holds different positions,
your engineering will reflect that. The patterns below are not
prescriptions. They are an existence proof that the constraints can be
taken seriously without the system collapsing.

The Halakhic Frame

Before the engineering, the framework. Engineering decisions made
without understanding what is actually forbidden produce either
excessive restriction that breaks the system or insufficient discipline
that violates the obligation. Both failure modes are common among
observant developers I have spoken with. The right response to either
is to understand the actual halakhic categories.

Shabbat prohibitions in classical halakha break into three layers.

The first layer is the thirty-nine melachot, the categories of
creative work derived from the construction of the Mishkan in the
desert. They are not the same as the modern category of physical labor.
Writing two letters of the alphabet is forbidden because writing was
required to construct the Mishkan. Carrying objects between domains is
forbidden for the same reason. Using fire is forbidden because fire was
used. The list is technical and counterintuitive to anyone unfamiliar
with it.

The second layer is the rabbinic enactments called shevut, which
extend or fence the biblical prohibitions. Many activities that are not
strictly within the thirty-nine melachot were nevertheless forbidden by
the Sages because they resemble forbidden categories, or because they
disturb the character of the day, or because they could lead to
biblical violations. Operating an electrical switch falls under shevut
according to most contemporary poskim, because it lights a fire (in the
case of incandescent bulbs) or because it completes an electrical
circuit (in the broader case).

The third layer is the principle of kavod Shabbat, the honoring of
the day, which is itself a positive commandment. This is more
qualitative than the prohibitions. The day must be different in
character from a weekday, even in ways not directly prohibited.

Cross-cutting all three layers is the principle of pikuach nefesh,
the saving of life, which overrides almost every Shabbat prohibition.
If a life is in danger, the prohibitions yield. Calling emergency
services on Shabbat to save a life is not merely permitted but
obligated. There is no halakhic conflict here.

There is also a recognized category of grama, indirect causation.
An action that I take before Shabbat which produces an effect during
Shabbat is, in many cases, not considered my act on Shabbat itself. I
plant a seed on Friday. It grows during Shabbat. The growing is not my
melachah. The classical example used by every contemporary discussion
of automation is the timer that turns lights on and off, set before
Shabbat, operating autonomously during it. The Sages explicitly
permitted this on the grounds that I am not performing the act when it
fires.

These are the categories that I bring to the engineering questions. The
question is never simply "is this allowed?" The question is always
"which category does this fall into, and what does that category
require?"

What Can Run Autonomously, and Why

The grama principle settles the easy cases. Any process that I have
configured and started before Shabbat, which then runs autonomously
during Shabbat without my intervention, is permissible. This includes
most of the operational backbone of a competent homelab.

Backups can run through Shabbat without halakhic complication. The
backup script fires at 02:00 every night, configured by an Ansible role
deployed weeks ago. The script copies bind-mounted directories, archives
Docker volumes, applies retention policy, writes a log. None of this
involves my agency on Shabbat. The system continues a process that I
set in motion through the original configuration. By the same reasoning
that allows a Shabbat timer to control lights, the backup is permitted.

Monitoring is similar in principle but more nuanced in application.
Loki ingests logs continuously. Prometheus scrapes targets every thirty
seconds. Grafana renders dashboards on demand. None of these processes
involve my agency once they are configured. They run regardless of
whether I am observing them. The complication is that I might be
tempted to look at the dashboards on Shabbat, which raises a different
question I will return to.

Scheduled jobs of all kinds are permitted to run through Shabbat
provided they were configured before. This includes the cron jobs that
generate the daily error digest from Loki, the systemd timer that
restarts wireguard at 06:00, the Proxmox vzdump nightly snapshot at
01:00, and the unattended-upgrades package update process that fires
on its own internal schedule. All of these were configured during
weekday work and continue without my intervention. None of them
constitute melachah on my part during their Shabbat execution.

Network services continue to serve other users without halakhic
issue. If a friend pushes to my self-hosted GitLab on a Saturday
afternoon, the GitLab daemon receives their push, writes the commit to
disk, updates references, and returns success. None of this is my act.
The friend's act is theirs to evaluate within their own framework.
GitLab is responding to their act, not to mine.

Automated alerting is more complex and gets its own section below.

The general principle here is straightforward. Autonomous continuation
of a process configured before Shabbat is not Shabbat work. The
homelab continues to function during Shabbat the same way an
agricultural field continues to function. Crops grow. Water flows. The
farmer rests. The system is fine.

The Deploy Pipeline Must Stop

The harder constraint is what cannot run during Shabbat, regardless of
how it was configured. Specifically, anything that constitutes a real
modification to the system, performed at my direction, that I have any
plausible role in initiating or overseeing.

Deploys are the clearest case. A deploy is the application of new
configuration or new code to a running system. It modifies the running
state. It produces creative output that did not previously exist. It is
melachah in the most direct sense, and the fact that I press a button
in GitLab to trigger it does not change the analysis. If the deploy
runs during Shabbat, even autonomously from a queued action, it is my
act in a way that ordinary scheduled jobs are not, because the deploy
represents a specific change I am applying rather than a continuation
of an established process.

The engineering response is straightforward. The deploy pipeline must
not run during Shabbat. This is implemented in two places.

The first is at the GitLab CI level. The runner configuration is set
to refuse jobs during the Shabbat window. The window is calculated from
sunset times, which are available through the Hebcal API for any
location. A small wrapper script around the runner checks the current
time against the calculated Shabbat window for Nottwil and exits
without claiming the job if the window is active. The job remains
queued. When Shabbat ends, the runner picks it up.

The second is at the Ansible level. The make targets that perform
production deploys check the same Shabbat window before executing. If
the window is active, the deploy refuses to run, with a clear error
message stating why. This prevents accidental Motzei Shabbat deploys
that I might initiate before sundown ends, and it prevents the rare
case of a different operator (a co-tenant, in my case) inadvertently
running a deploy on my behalf.

The implementation is approximately fifty lines of Python plus the
Hebcal API integration. The full code lives in the homelab-orchestra
repository alongside the rest of the operational infrastructure. It is
short and unremarkable. The discipline it enforces is significant.

The Alerting Problem

Alerting is where the halakhic categories collide with the operational
realities, and the solution requires more thought than either the
backups case or the deploys case.

The backbone problem is this. My homelab generates alerts. Some of
those alerts are operational, like a disk approaching ninety percent
capacity or a backup failing. Others are time-sensitive in ways that
matter, like a security incident or a service outage that affects
people relying on me. None of them are pikuach nefesh in the formal
sense, because the homelab is not a hospital and no one is in physical
danger if Grafana goes down.

The question is what to do with these alerts during Shabbat.

The classical halakhic answer to "what about this notification I might
receive" is straightforward. Do not check it. The phone is silenced for
the duration of Shabbat in any case. Notifications that arrive are not
my responsibility to act on. They will be there after Shabbat ends. If
the disk genuinely fills up and the service degrades, the world does
not end. The disruption is recoverable on Motzei Shabbat.

The operational engineering response is to make this stance technically
sustainable, which means three specific things.

First, every alert must be tagged with a severity that reflects whether
it can wait twenty-five hours. The Grafana alert rules in the homelab
distinguish between info, warning, and critical levels.
Info and warning alerts go to email and queue silently. Critical alerts
do as well, with the understanding that critical in this context still
means something I will read on Motzei Shabbat, not something I will act
on during. The category that would actually require Shabbat action is
absent from the alerting tree by design. If a true pikuach-nefesh
condition occurred, it would not arrive through Grafana. It would
arrive through whatever channel the actual emergency uses.

Second, the system must be capable of self-protection during the
twenty-five hours when no operator will respond. This means automated
remediation for the failure modes most likely to compound. The disk
filling up is handled by automated log rotation and by the backup
script's retention enforcement. Containers that crash are restarted
automatically by Docker's restart policy. Services that go unreachable
are not auto-replaced, but they also do not propagate failure into
neighboring services because the architecture isolates them. The
homelab is built to degrade gracefully, not because Shabbat requires
it, but because any sufficiently mature operations practice requires
it. Shabbat just makes the requirement explicit.

Third, the post-Shabbat triage process is structured to handle the
backlog efficiently. The first hour after Shabbat ends, every Saturday
night, includes reading the email queue, scanning the alert
dashboard, and addressing whatever accumulated during the twenty-five
hours. This is part of the rhythm of the week. It is not an emergency
response. It is a scheduled review.

The combined effect is that my homelab is not actually different in
operational character from a competent on-call rotation that hands off
on Friday evening and resumes on Saturday night. The operator is
unavailable for a defined window. The system is configured to handle
the window. The handoff is explicit. This is good operations practice
generally. It is also halakhic compliance.

The Question of Looking at Dashboards

The hardest question, the one that took me the longest to think
through, is what to do with the temptation to look at the homelab on
Shabbat.

The temptation is not unique to me. Every operator I know has the
reflex to check the dashboard. It is not work in any meaningful
operational sense. Reading a dashboard does not modify state, does not
produce output, does not deploy anything. Strictly within the
thirty-nine melachot, looking at a Grafana panel is not an obvious
violation.

The complication is that looking at the dashboard plausibly violates
kavod Shabbat, the qualitative requirement that the day be
different in character. Reading work-adjacent monitoring during
Shabbat keeps the operator psychologically inside the work frame, even
if no specific melachah is performed. It also raises the secondary
risk that I will see something concerning and feel pressure to act,
which would lead to actual violation.

The engineering response, on reflection, is to make the dashboards
inaccessible during Shabbat rather than to rely on personal discipline
to avoid them. The Caddy configuration that fronts Grafana applies a
time-based access rule. During the Shabbat window, requests to the
Grafana host return a static page that explains the closure and
includes the Hebrew word for Shabbat. The dashboards remain
operational internally. The Loki and Prometheus instances continue
ingesting and recording. Only the human-facing UI is gated.

This works because the gating is itself configured before Shabbat. The
Caddy config is templated, deployed by Ansible during weekday work,
and reads the Shabbat window from the same Hebcal-derived calculation
used by the deploy pipeline. The static page is served by Caddy
itself, requiring no Grafana process. When Shabbat ends, the gate
lifts automatically. No manual intervention is required at any point
during the twenty-five hours.

The effect of this small technical decision is larger than expected.
The temptation to peek dies when peeking returns the same static page
every time. The frame of mind shifts. Shabbat actually becomes
qualitatively different. The infrastructure stops being a thing I am
adjacent to and becomes a thing that is genuinely outside my
attention. This is, in the end, the entire point of Shabbat. The
engineering decision serves the religious obligation rather than
fighting it.

Where the Categories Get Difficult

Three cases remain where I am still uncertain about the right
configuration, and I would rather mention them honestly than pretend
the framework is complete.

The first is automated security responses. If my homelab detects a
genuine security incident during Shabbat, what should it do? The
default operations answer is to alert me. But under the principles
above, alerts during Shabbat are read on Motzei Shabbat. By the time
I read it, the incident may have caused real harm. The alternative is
to let the system respond autonomously, which is permissible by the
grama principle, but raises the engineering question of how
sophisticated that response can be without producing false positives
that would constitute their own incident. I have not fully resolved
this. The current configuration is conservative automated response,
specifically firewall rules that block sources observed exhibiting
known attack patterns, with no more sophisticated remediation
attempted. I am open to the possibility that this is too restrictive.

The second is the question of friends and family using my services.
If a friend pushes to my GitLab on a Saturday afternoon, GitLab
responds to them. This is fine for non-Jewish friends. It raises a
question for Jewish friends, because by hosting their commit, I might
be facilitating their Shabbat violation, which is a concern under the
principle of lifnei iver, do not place a stumbling block before the
blind. Most contemporary poskim hold that simply hosting a service
does not constitute lifnei iver in this case, because the service is
available to many users for many reasons, and the Jewish friend is
making their own choice. But I am not entirely settled on the
question, and I do think about it.

The third is the boundary case of monitoring on a phone display
that I can see by accident. If my phone is silent but the screen
lights up briefly when an alert arrives, and I see it from across the
room, have I now seen monitoring information during Shabbat? My
current configuration silences notifications entirely, with no
visible component, but this is a configuration choice that has to be
made deliberately. The default behavior of every notification system
in 2026 is the opposite.

These are open questions. I mention them because honest engineering
should distinguish between the parts of a system you have figured out
and the parts you have not.

Why This Is Engineering Rather than Constraint

The objection I have heard most often when explaining this work is
that the halakhic frame is a constraint that limits what the system
can do. The objection is wrong, and the way it is wrong is worth
naming.

The thirty-nine melachot are not a list of capabilities I am giving
up. They are a discipline that forces every other engineering
decision to be more deliberate. The deploy pipeline that refuses to
run during a defined window is more reliable, not less, than a
pipeline that runs at any moment. The alerting that distinguishes
critical from operational is better designed, not worse, than
alerting that pages constantly. The dashboard that returns a static
page during Shabbat is more thoughtfully built than a dashboard that
is always on.

In every case, the halakhic constraint forces me to articulate a
question that an unconstrained operator can avoid. What does the
deploy pipeline do when the operator is unavailable? What is the
distinction between an alert that requires immediate response and one
that does not? What does the system provide that genuinely needs the
operator versus what it provides that the operator merely wants to
see? These are good questions. They produce better infrastructure
when answered.

This is, I think, the deeper structure of every serious religious
discipline in any tradition. The constraints are not in tension with
excellence. They are the conditions for it. Without the constraints,
the work expands to fill all available time and attention, and the
quality declines. With them, the work has to fit within bounds, and
the discipline of fitting it improves the work itself.

I run a more disciplined homelab because I rest on Shabbat. The two
are not in opposition. They are the same practice viewed from
different angles.

Closing

If you are an observant Jew who works in infrastructure and you have
been quietly figuring out the same questions on your own, this post
is for you. The patterns above are not the final word. They are one
operator's attempt to take both halves of the obligation seriously,
the technical and the religious, and to find configurations that
serve both without compromising either.

If you are a non-Jewish engineer who finds this strange, my hope is
that it is at least interesting. The deeper claim is that any
serious commitment outside the work, religious or otherwise, can
function as the discipline that improves the work. Shabbat is the
specific form this takes for me. Other forms exist for other
operators. The principle generalizes. Constraint is not the enemy of
craft. It is the condition.

If you are a posek who reads this and thinks I have made a mistake on
some specific point, I welcome the correction. The whole project is
provisional. It improves through dialogue. That is the point of doing
it in writing rather than alone in a server closet on a Friday
afternoon, watching the sun.