My workstation does a lot. It is a Linux desktop, development machine, local AI environment, Godot workstation, Blender workstation, Git client & general troubleshooting system.
That is useful, but every new capability adds something I need to understand. A development server can open a port. An IDE extension can read a repository. An AI tool may receive shell access. Git credentials can unlock remote repositories.
So I wanted the security model to grow with the workstation instead of pretending the operating system alone would take care of it.
Keep a powerful daily-use workstation understandable enough that convenience does not quietly become unnecessary exposure.
1. Why Bazzite
Bazzite is the Linux environment I am currently using for day-to-day work. It gives me a stable desktop while still letting me work deeply with Linux tooling, development workflows & containers.
I also use the same machine for Steam access during downtime. That was part of the decision too. I did not want a workstation that forced me to maintain a completely separate Windows system just so I could relax, play something for a bit & then return to work. Having that gaming access built into the same Linux environment makes the system more practical & accessible for how I actually use it.
That matters to me because a workstation has to fit real life, not just look good in a security checklist. If the platform is comfortable enough for daily work, development & downtime, I am much more likely to keep using, maintaining & understanding the same environment instead of splitting everything across machines I touch less often.
The image-based/atomic style of the system also changes how I think about software installation. I need to be conscious of which layer software belongs in instead of automatically installing everything directly into the host operating system.
That separation can be useful because it encourages me to think about what really needs host-level access.
2. Know where software comes from
One of the easiest ways for a workstation to become difficult to maintain is to install software from five different ecosystems & forget which one owns what.
System packages, Flatpaks, containers, language package managers, AppImages & manual binaries can all be valid choices. The security & maintenance problem appears when I stop knowing where an application came from or how it receives updates.
I want software provenance to remain understandable: where did this come from, who updates it & how would I remove it?
3. Developer services are still services
A local web server, model server or debugging endpoint can feel harmless because I started it for development.
The network does not care why I started it. If it is listening on an external interface, other systems may be able to reach it.
So I periodically inspect listening services & ask whether they still need to exist. Temporary development exposure should not become permanent just because I forgot about it.
4. The workstation holds keys to other systems
The machine itself is only part of the value. It can also hold SSH keys, GitHub sessions, browser sessions, API tokens & credentials for other services.
That means workstation compromise can become account or infrastructure compromise.
I try to keep credentials scoped, avoid committing secrets into repositories & think about what would need to be rotated if the machine were lost or compromised.
5. AI tooling changed the trust model
AI-assisted development is now part of the workstation. Some tools only receive text I explicitly provide. Others can inspect repositories, edit files or execute commands.
Those are completely different permission levels.
I want to know which category a tool belongs to before I treat it as harmless convenience. A model with shell access is effectively another actor operating under my user permissions.
That does not mean I avoid it. It means I treat the access as real.
6. Recovery changes how risky experimentation feels
I do a lot of experimentation, so I need the machine to be recoverable. Git protects project history. Backups protect important files. Documentation protects configuration knowledge.
Recovery is part of security because it changes the impact of failure. A mistake is much less catastrophic when the important state exists somewhere else & I know how to rebuild the environment.
Security is not only stopping bad things from happening. It is also reducing how much damage a bad event can cause.
7. I want normal behavior to feel familiar
The more comfortable I become with processes, services, logs, ports & configuration, the easier it is to notice when something does not fit.
I do not need to stare at logs all day. I just do not want the system to be a black box.
If something starts listening unexpectedly or a service fails repeatedly, I want to have enough familiarity with the machine to investigate instead of immediately reinstalling everything.
8. The result
The workstation is now a stable base for the work I actually do: Linux administration, web development, Git, local AI, Godot, Blender, cybersecurity practice & technical experimentation.
It also gives me Steam access for downtime without needing to leave the Linux environment, which makes the workstation more useful as an everyday system instead of something I only open when I am working.
More importantly, I am getting better at understanding the relationships between those tools instead of treating each one as an isolated application.
The project is never really finished
A secure workstation is not a one-time build. New tools change the attack surface. New projects introduce new credentials. Updates change software. My own workflow changes.
So I consider the initial build complete, but maintenance is ongoing. The deeper reasoning & practical checks are documented in the related writeup.