Define Your SQL Server Standard Once. Build to It in Minutes.
The free roadmap for DBAs moving from checklists and scattered scripts to Ansible, so you can stop wondering whether production still matches what you built. Take the 60-second audit to see where you stand today.
How are new database servers and settings deployed in your environment?
Select your baseline to calculate your team's automation maturity stage:
Running scattered PowerShell and SQL scripts each person maintains separately.
Shared Git repository of scripts with heavy defensive boilerplate.
Ansible playbooks or DSC configurations build and configure servers without running scripts by hand.
Your Servers Shouldn't Depend on Who Built Them
When builds depend on one person's clicks, scripts, or memory, servers drift apart, new builds take days, and nobody wants to test changes. Here's the alternative.
Silent Configuration Drift
Every server reflects whoever built it. Folder paths, collation, TempDB settings, and trace flags drift without notice between Dev, QA, and Production.
Define your server foundation in code, then check any server against it to see exactly what drifted. Every build comes out identical.
The Multi-Day Build Bottleneck
Provisioning a new SQL Server instance or cluster takes days of clicking through setup wizards, running disconnected PowerShell scripts, and waiting on infrastructure handoffs.
Ansible playbooks build and configure servers to your standard in minutes. Anyone on the team can run them, not only the person who wrote them.
The Production "Fear Factor"
Testing new configurations or learning automation against production or shared test environments is risky, so most teams avoid it altogether.
Build realistic Windows and Linux labs on your own workstation. Snapshot, break, and rebuild them whenever you want, with no cloud bills.
Luke Campbell
20-Year Enterprise Production DBA
Founder & Principal Instructor
Why I Built AutomateSQL
I started in Windows systems administration and moved into SQL Server in 2006. In the 20 years since, I've seen the same problem at company after company: build documents nobody updates, and servers that were each built a little differently.
One person formats drives with the default block size, while another uses 64KB. One person names folders Data and Logs, while another uses Data and Log. Add everyone's private stash of scripts, and nobody can say for sure how any server was actually built.
It gets worse across teams. Most DevOps training assumes Linux, so Windows shops get little guidance. Meanwhile, DBAs are left hoping the sysadmin on this project configures storage and the OS the same way the last one did.
I built AutomateSQL so DBAs can fix that themselves: define the standard for the whole server (OS, storage, and SQL Server) in code, build to it every time, and check against it whenever they need to.
Here you'll find the blueprints and hands-on labs to do that, starting with Windows and Linux environments you can build, break, and rebuild on your own machine.
— Luke Campbell
AutomateSQL.com
From Manual Builds to Desired State
Start where you are, practice somewhere safe, then bring it to work.
Find Where You Stand
Take the 60-second assessment in the free roadmap. See your team's automation level, where your scripts hit their ceiling, and what to fix first.
Build a Safe Lab
Build a disposable Windows, Linux, and Active Directory lab on your own computer. It's your flight simulator: practice automation, break things, and reset without touching production or paying for cloud.
Automate Your Standard
Learn Ansible and write playbooks that build servers to your standard and check any server against it. Then bring them to work, so your builds stop depending on who ran them.
The Database Platform Automation Roadmap
From Manual Builds to Desired State
Free. Instant access.