If you work in IT long enough, you eventually write something useful.
A cleanup script. A bulk automation tool. An onboarding workflow. A reporting utility.
And then you think:
“This would make a great GitHub project.”
And immediately after:
“Wait… am I even allowed to publish this?”
This question comes up constantly in sysadmin and DevOps communities — especially among prosumers who:
- Work in IT professionally
- Run homelabs at home
- Want to build a public portfolio
- Care about reputation and credibility
The tension is real:
You want to build in public.
But you don’t want to violate policy, IP law, or trust.
Let’s break this down clearly.
Step 1: Assume Your Employer Owns the Original Script
In most employment agreements:
- Code written during work hours
- Code written using company resources
- Code written to solve company problems
…belongs to the employer.
Even if:
- It’s “just a PowerShell script”
- It’s only 50 lines
- It feels generic
You should assume the original file is not yours to publish.
That’s the safe baseline.
Step 2: Separate Idea From Implementation
Here’s the key mindset shift:
You don’t own the original implementation.
But you do own your knowledge.
Example:
At work you write:
- A script that disables stale AD users
- A report generator for cloud cost tracking
- A disk cleanup utility
- A service health monitor
The idea of those automations is not proprietary.
The specific implementation may be.
So instead of publishing:
disable-stale-users.ps1 (copied from work repo)
You recreate the logic from scratch in your homelab.
Different:
- Variable names
- Structure
- Logging style
- Error handling
- Parameterization
Same general automation concept.
That’s ethical. That’s safe. That’s professional.
Step 3: Rebuild It in Your Homelab
This is where homelabs shine.
Your homelab becomes:
- A sandbox to re-implement patterns
- A place to generalize workflows
- A testing ground for making scripts reusable
Example workflow:
- Identify automation pattern used at work
- Rebuild a generic version in lab
- Remove environment-specific logic
- Parameterize everything
- Add documentation
- Add safety flags (WhatIf / DryRun)
- Publish clean, neutral version
You are not leaking IP.
You are demonstrating engineering maturity.
Step 4: Strip Company-Specific Context
Before publishing anything, check for:
- Internal server names
- Domain names
- OU structures
- File paths
- Proprietary APIs
- Ticketing system references
- Hard-coded business logic
Bad example:
Get-ADUser -SearchBase "OU=CorpUsers,DC=company,DC=local"
Good example:
param(
[string]$SearchBase
)
Get-ADUser -SearchBase $SearchBase
Make it generic. Make it reusable. Make it environment-agnostic.
Step 5: Never Share Data
Even sanitized scripts can accidentally include:
- Sample exports
- Real usernames
- Internal IDs
- Logs
Always:
- Use fake domains (example.com)
- Use placeholder data
- Generate mock data
- Remove real output samples
Step 6: When in Doubt — Ask
Some companies explicitly allow:
- Publishing generic utilities
- Maintaining public GitHub
- Contributing to open source
Some do not.
If you’re unsure:
Ask your manager or HR in a neutral way:
“Are there guidelines about publishing generic scripts or open-source contributions?”
That conversation alone signals professionalism.
Why This Matters for Your Career
Prosumers want:
- Public GitHub
- Visible proof of skill
- Credibility
- Recruiter leverage
But the real value isn’t clout.
It’s this:
When you rebuild production logic in your homelab in a generalized, documented, reusable way —
You become a better engineer.
You move from:
“Person who writes scripts”
To:
“Person who designs automation patterns”
That’s a career shift.
A Safe Publishing Checklist
Before pushing to GitHub, confirm:
- No company-specific names
- No internal domains
- No proprietary integrations
- No copied code
- Written from scratch
- Parameterized
- Documented
- Tested in lab only
If all are true, you’re likely in safe territory.
Turning Work Automation Into Portfolio Assets
Here’s a powerful pattern:
Instead of publishing:
“AD Offboarding Script for Company X”
Publish:
“PowerShell Script to Disable Inactive Directory Users with Logging and Dry Run”
Instead of:
“Internal Backup Cleanup Tool”
Publish:
“Bash Script to Remove Backup Archives Older Than X Days”
Generalize. Neutralize. Professionalize.
Final Thought
Homelabs aren’t just for tinkering.
They’re for:
- Rebuilding production ideas safely
- Sharpening engineering discipline
- Creating portfolio-grade automation
- Practicing ethical professionalism
Publishing scripts isn’t about ego.
It’s about growth.
Just make sure you build them the right way.
Here are some templates you can use to publish publically: