Fullmer Wiki - User contributions [en]

MediaWiki:Common.js

2026-08-21T19:41:46Z

Brett: Add loop attribute, swap in the upgraded 25s video

/* Inject a masthead matching brettfullmer.com's header, with a working hamburger menu. */
( function () {
var header = document.createElement( 'header' );
header.id = 'bf-masthead';
header.innerHTML =
'<div class="bf-wrap">' +
'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="" width="24" height="24">Brett Fullmer</a>' +
'<div class="bf-mobile-actions">' +
'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'<button class="bf-toggle" aria-label="Toggle menu" aria-expanded="false">' +
'<span></span><span></span><span></span>' +
'</button>' +
'</div>' +
'<nav class="bf-links" id="bf-nav-links">' +
'<a href="https://brettfullmer.com/#about">What I Do</a>' +
'<a href="https://brettfullmer.com/#experience">Experience</a>' +
'<a href="https://brettfullmer.com/#sabbatical">AI Lab</a>' +
'<a href="https://brettfullmer.com/blog/">Blog</a>' +
'<a href="/wiki/Main_Page" class="bf-current">Wiki</a>' +
'<a class="bf-cta bf-cta-desktop" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'</nav>' +
'</div>';

document.body.insertBefore( header, document.body.firstChild );

var toggle = header.querySelector( '.bf-toggle' );
var links = header.querySelector( '.bf-links' );
toggle.addEventListener( 'click', function () {
var isOpen = links.classList.toggle( 'open' );
toggle.classList.toggle( 'open', isOpen );
toggle.setAttribute( 'aria-expanded', isOpen ? 'true' : 'false' );
} );
links.querySelectorAll( 'a' ).forEach( function ( a ) {
a.addEventListener( 'click', function () {
links.classList.remove( 'open' );
toggle.classList.remove( 'open' );
toggle.setAttribute( 'aria-expanded', 'false' );
} );
} );
}() );
/* Inject the build-flow video into its placeholder (raw <video> tags get sanitized by MediaWiki) */
( function () {
var placeholder = document.getElementById( 'wiki-video-spacelift-build' );
if ( !placeholder ) return;
placeholder.innerHTML =
'<video controls loop preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" style="max-width:728px;width:100%;height:auto;">' +
'<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">' +
'Your browser does not support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.' +
'</video>';
}() );

MediaWiki:Common.css

2026-08-21T19:20:14Z

Brett: Style video frame

/* ===== Fullmer Wiki: match brettfullmer.com brand ===== */

@font-face {
font-family: "Alfa Slab One";
src: url("/fonts/AlfaSlabOne-Regular.ttf") format("truetype");
font-weight: 400;
font-display: swap;
}

@font-face {
font-family: "Oswald";
src: url("/fonts/Oswald.ttf") format("truetype");
font-weight: 200 700;
font-display: swap;
}

:root {
--bf-paper: #f2e8d2;
--bf-paper-2: #eaddbd;
--bf-card: #f8f0dc;
--bf-ink: #191410;
--bf-ink-soft: #4a3f33;
--bf-muted: #7a6b58;
--bf-red: #c9342a;
--bf-mustard: #e0a92e;
--bf-teal: #2f7f74;
--bf-slab: "Alfa Slab One", "Rockwell", serif;
--bf-cond: "Oswald", "Arial Narrow", sans-serif;
--bf-serif: Georgia, "Times New Roman", serif;
}

/* ---------- Custom masthead (injected by Common.js) ---------- */
#bf-masthead {
position: sticky;
top: 0;
z-index: 200;
background: var(--bf-paper);
border-bottom: 3px solid var(--bf-ink);
box-shadow: 0 3px 0 rgba(25, 20, 16, 0.12);
font-family: var(--bf-cond);
}

#bf-masthead .bf-wrap {
max-width: 1100px;
margin: 0 auto;
padding: 0 24px;
display: flex;
justify-content: space-between;
align-items: center;
height: 66px;
position: relative;
}

#bf-masthead .bf-name {
font-family: var(--bf-slab);
font-size: 19px;
color: var(--bf-ink);
text-decoration: none;
display: flex;
align-items: center;
}

#bf-masthead .bf-name:hover { color: var(--bf-red); }

#bf-masthead .bf-name img {
width: 24px !important;
height: 24px !important;
max-width: 24px !important;
max-height: 24px !important;
flex-shrink: 0;
object-fit: contain;
margin-right: 9px;
}

#bf-masthead .bf-links {
display: flex;
gap: 24px;
align-items: center;
}

#bf-masthead .bf-links a {
color: var(--bf-ink-soft);
font-family: var(--bf-cond);
font-size: 14px;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 1.5px;
text-decoration: none;
}

#bf-masthead .bf-links a:hover,
#bf-masthead .bf-links a.bf-current { color: var(--bf-red); }

#bf-masthead .bf-cta {
font-family: var(--bf-cond);
font-size: 14px;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 1.5px;
background: var(--bf-red);
color: var(--bf-paper) !important;
border: 2px solid var(--bf-ink);
padding: 8px 18px;
border-radius: 6px;
box-shadow: 3px 3px 0 var(--bf-ink);
text-decoration: none;
transition: transform 0.15s, box-shadow 0.15s;
}

#bf-masthead .bf-cta:hover { transform: translate(-1px, -1px); box-shadow: 4px 4px 0 var(--bf-ink); }

#bf-masthead .bf-mobile-actions { display: none; align-items: center; gap: 12px; }

#bf-masthead .bf-toggle {
display: none;
flex-direction: column;
justify-content: center;
gap: 5px;
width: 32px;
height: 32px;
background: none;
border: none;
padding: 0;
cursor: pointer;
}

#bf-masthead .bf-toggle span {
display: block;
width: 100%;
height: 3px;
background: var(--bf-ink);
border-radius: 2px;
transition: transform 0.2s ease, opacity 0.2s ease;
}

#bf-masthead .bf-toggle.open span:nth-child(1) { transform: translateY(8px) rotate(45deg); }
#bf-masthead .bf-toggle.open span:nth-child(2) { opacity: 0; }
#bf-masthead .bf-toggle.open span:nth-child(3) { transform: translateY(-8px) rotate(-45deg); }

@media (max-width: 680px) {
#bf-masthead .bf-mobile-actions { display: flex; }
#bf-masthead .bf-toggle { display: flex; }
#bf-masthead .bf-links .bf-cta-desktop { display: none; }

#bf-masthead .bf-links {
position: absolute;
top: 66px;
left: 0;
right: 0;
flex-direction: column;
align-items: stretch;
gap: 0;
background: var(--bf-paper);
border-bottom: 3px solid var(--bf-ink);
box-shadow: 0 3px 0 rgba(25, 20, 16, 0.12);
max-height: 0;
overflow: hidden;
opacity: 0;
pointer-events: none;
transition: max-height 0.25s ease, opacity 0.2s ease;
}

#bf-masthead .bf-links.open {
max-height: 500px;
opacity: 1;
pointer-events: auto;
}

#bf-masthead .bf-links a {
padding: 16px 24px;
border-bottom: 1px solid rgba(25, 20, 16, 0.1);
}
}

/* ---------- Recolor the wiki body itself ---------- */
body {
background-color: var(--bf-paper) !important;
color: var(--bf-ink) !important;
font-family: var(--bf-serif) !important;
}

.mw-page-container, .mw-body, #content {
background: transparent !important;
}

.mw-body {
background: var(--bf-card) !important;
border: 3px solid var(--bf-ink) !important;
border-radius: 10px !important;
box-shadow: 6px 6px 0 var(--bf-ink) !important;
padding: 30px 34px !important;
}

.mw-body h1, .mw-body h2, .mw-body h3 {
font-family: var(--bf-slab) !important;
font-weight: 400 !important;
color: var(--bf-ink) !important;
border-bottom-color: rgba(25, 20, 16, 0.2) !important;
}

.mw-body a, .vector-menu-content a { color: var(--bf-red) !important; }
.mw-body a.new { color: var(--bf-teal) !important; }

.vector-pinnable-header, .vector-menu-heading, #p-navigation h3, #p-tb h3 {
font-family: var(--bf-cond) !important;
text-transform: uppercase;
letter-spacing: 1px;
}

pre, .mw-highlight, code {
background: var(--bf-paper-2) !important;
border-color: var(--bf-ink) !important;
}
/* ===== Deep Vector restyle: kill the white, match the retro palette ===== */

html { background: var(--bf-paper) !important; }

.mw-page-container,
#mw-content-text,
.vector-body,
.mw-body-content,
.skin-vector-2022 {
background: transparent !important;
}

/* ---------- Vector's own top bar (logo/search/login) ---------- */
.vector-header-container,
header.vector-header,
.vector-pinnable-header-toolbar {
background: var(--bf-paper-2) !important;
border-bottom: 3px solid var(--bf-ink) !important;
box-shadow: none !important;
}

.vector-header-container .mw-logo-wordmark,
.vector-header-container .mw-logo-container {
filter: none !important;
}

/* ---------- Search box ---------- */
.cdx-search-input__input-wrapper .cdx-text-input__input,
.cdx-text-input__input,
#searchInput {
background: var(--bf-card) !important;
border: 2px solid var(--bf-ink) !important;
color: var(--bf-ink) !important;
font-family: var(--bf-serif) !important;
box-shadow: none !important;
}

.cdx-text-input__input:focus {
border-color: var(--bf-red) !important;
box-shadow: 0 0 0 1px var(--bf-red) !important;
}

.cdx-search-input__end-button,
.cdx-button {
font-family: var(--bf-cond) !important;
}

/* Primary buttons (Search button, Save changes, etc.) */
.cdx-button--action-progressive,
.cdx-button--weight-primary.cdx-button--action-progressive,
#p-search .cdx-button,
.mw-ui-button.mw-ui-progressive {
background: var(--bf-red) !important;
border: 2px solid var(--bf-ink) !important;
color: var(--bf-paper) !important;
box-shadow: 2px 2px 0 var(--bf-ink) !important;
border-radius: 6px !important;
}

/* ---------- Left sidebar (navigation, tools) ---------- */
#mw-panel,
.vector-main-menu-container,
.mw-portlet {
background: transparent !important;
}

.vector-menu-heading,
.mw-portlet-label {
font-family: var(--bf-slab) !important;
color: var(--bf-ink) !important;
font-weight: 400 !important;
text-transform: none !important;
letter-spacing: normal !important;
border-bottom: 1px solid rgba(25, 20, 16, 0.15) !important;
}

.vector-menu-content a,
.mw-portlet a {
color: var(--bf-ink-soft) !important;
font-family: var(--bf-cond) !important;
}

.vector-menu-content a:hover,
.mw-portlet a:hover {
color: var(--bf-red) !important;
text-decoration: underline;
}

/* ---------- Page tabs (Read / Edit / View history / Tools) ---------- */
#p-views a,
#p-associated-pages a,
.vector-tab-noicon a,
#p-namespaces a {
color: var(--bf-ink-soft) !important;
font-family: var(--bf-cond) !important;
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.5px;
}

#p-views .selected a,
#p-namespaces .selected a {
color: var(--bf-red) !important;
border-bottom: 2px solid var(--bf-red) !important;
}

.vector-page-toolbar,
#left-navigation,
#right-navigation {
background: transparent !important;
}

/* ---------- Table of contents / Appearance panel ---------- */
#toc, .toc,
.vector-toc,
.vector-pinnable-element {
background: var(--bf-card) !important;
border: 2px solid var(--bf-ink) !important;
border-radius: 8px !important;
}

.vector-toc-list a,
.sidebar-toc a {
color: var(--bf-ink-soft) !important;
font-family: var(--bf-cond) !important;
}

.vector-toc-list a:hover { color: var(--bf-red) !important; }

/* Codex radio buttons (Appearance: text size / width) */
.cdx-radio__icon {
border-color: var(--bf-ink) !important;
}

.cdx-radio__input:checked + .cdx-radio__icon {
background-color: var(--bf-red) !important;
border-color: var(--bf-red) !important;
}

.cdx-radio__label {
font-family: var(--bf-serif) !important;
color: var(--bf-ink) !important;
}

/* ---------- Footer ---------- */
#footer, .mw-footer, footer.mw-footer-container {
background: var(--bf-paper-2) !important;
border-top: 2px solid var(--bf-ink) !important;
color: var(--bf-muted) !important;
font-family: var(--bf-cond) !important;
}

#footer a, .mw-footer a { color: var(--bf-teal) !important; }

/* ---------- Misc form elements everywhere (edit forms, etc.) ---------- */
input[type="text"], input[type="search"], textarea, select {
background: var(--bf-card) !important;
border: 2px solid var(--bf-ink) !important;
color: var(--bf-ink) !important;
font-family: var(--bf-serif) !important;
}
/* ===== Fix: hide Vector's own placeholder logo (we have our own masthead), kill overflow, kill remaining white ===== */

.mw-logo, .mw-logo-container, .mw-logo-icon, .mw-logo-wordmark {
display: none !important;
}

* { box-sizing: border-box !important; }

html, body {
overflow-x: hidden !important;
max-width: 100% !important;
}

.mw-body,
.vector-column-start,
.vector-column-end,
.mw-page-container-inner,
.vector-page-toolbar,
.vector-body {
max-width: 100% !important;
}

.mw-body {
margin-left: 0 !important;
}

@media (max-width: 719px) {
.mw-body {
padding: 20px 18px !important;
}
}

/* leftover white containers */
.vector-page-toolbar-container,
.vector-column-start,
.vector-column-end,
.mw-page-container-inner,
.vector-sticky-pinned-container,
.vector-pinnable-header {
background: transparent !important;
}

.vector-pinnable-element {
background: var(--bf-card) !important;
}
/* Kill the remaining white behind pinned/dropdown wrapper containers */
.vector-pinned-container,
.vector-unpinned-container,
.vector-dropdown-content,
.vector-menu-content-list {
background: transparent !important;
}
/* Kill white behind thumbnail images, give them the retro frame treatment */
figure.mw-halign-right,
figure.mw-halign-left,
figure.mw-halign-center,
figure.mw-default-size,
.mw-file-description,
.mw-file-element,
.thumb, .thumbinner {
background: transparent !important;
}

.mw-file-element {
border: 3px solid var(--bf-ink) !important;
border-radius: 8px !important;
box-shadow: 5px 5px 0 var(--bf-ink) !important;
}

figcaption, .thumbcaption {
background: transparent !important;
color: var(--bf-muted) !important;
font-family: var(--bf-cond) !important;
font-size: 0.85em !important;
}
/* Kill the white sticky header that slides in on scroll */
.vector-sticky-header,
#vector-sticky-header,
.vector-sticky-header-container {
background: var(--bf-paper-2) !important;
border-bottom: 2px solid var(--bf-ink) !important;
}

.vector-sticky-header .cdx-text-input__input,
.vector-sticky-header input {
background: var(--bf-card) !important;
border-color: var(--bf-ink) !important;
}

.vector-sticky-header-context-bar,
.vector-sticky-header-icon-end {
color: var(--bf-ink) !important;
}
/* Broad safety net: nothing in the sidebar columns should ever be plain white */
.vector-column-start,
.vector-column-start *,
.vector-column-end,
.vector-column-end * {
background-color: transparent !important;
}

.vector-pinnable-element {
background-color: var(--bf-card) !important;
}
/* Video frame to match the retro card treatment */
.wiki-video-frame {
margin: 20px 0;
}

.wiki-video-frame video {
border: 4px solid var(--bf-ink) !important;
border-radius: 12px !important;
box-shadow: 7px 7px 0 var(--bf-ink) !important;
display: block;
}

MediaWiki:Common.js

2026-08-21T19:19:39Z

Brett: Inject build-flow video via JS

/* Inject a masthead matching brettfullmer.com's header, with a working hamburger menu. */
( function () {
var header = document.createElement( 'header' );
header.id = 'bf-masthead';
header.innerHTML =
'<div class="bf-wrap">' +
'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="" width="24" height="24">Brett Fullmer</a>' +
'<div class="bf-mobile-actions">' +
'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'<button class="bf-toggle" aria-label="Toggle menu" aria-expanded="false">' +
'<span></span><span></span><span></span>' +
'</button>' +
'</div>' +
'<nav class="bf-links" id="bf-nav-links">' +
'<a href="https://brettfullmer.com/#about">What I Do</a>' +
'<a href="https://brettfullmer.com/#experience">Experience</a>' +
'<a href="https://brettfullmer.com/#sabbatical">AI Lab</a>' +
'<a href="https://brettfullmer.com/blog/">Blog</a>' +
'<a href="/wiki/Main_Page" class="bf-current">Wiki</a>' +
'<a class="bf-cta bf-cta-desktop" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'</nav>' +
'</div>';

document.body.insertBefore( header, document.body.firstChild );

var toggle = header.querySelector( '.bf-toggle' );
var links = header.querySelector( '.bf-links' );
toggle.addEventListener( 'click', function () {
var isOpen = links.classList.toggle( 'open' );
toggle.classList.toggle( 'open', isOpen );
toggle.setAttribute( 'aria-expanded', isOpen ? 'true' : 'false' );
} );
links.querySelectorAll( 'a' ).forEach( function ( a ) {
a.addEventListener( 'click', function () {
links.classList.remove( 'open' );
toggle.classList.remove( 'open' );
toggle.setAttribute( 'aria-expanded', 'false' );
} );
} );
}() );
/* Inject the build-flow video into its placeholder (raw <video> tags get sanitized by MediaWiki) */
( function () {
var placeholder = document.getElementById( 'wiki-video-spacelift-build' );
if ( !placeholder ) return;
placeholder.innerHTML =
'<video controls preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" style="max-width:728px;width:100%;height:auto;">' +
'<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">' +
'Your browser does not support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.' +
'</video>';
}() );

Spacelift

2026-08-21T19:18:11Z

Brett: Use JS-injected video placeholder (raw video tag gets sanitized)

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

== Watch it happen ==

Brett sketches the architecture, MAC turns it into OpenTofu config, Spacelift plans it and waits for a human to confirm before anything touches AWS. That's the whole loop:

<div class="wiki-video-frame" id="wiki-video-spacelift-build"></div>

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id <stack-id></code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
instance_id = aws_instance.web.id
state = "stopped" # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:AI Agents]]

Spacelift

2026-08-21T19:16:24Z

Brett: Add build-flow video

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

== Watch it happen ==

Brett sketches the architecture, MAC turns it into OpenTofu config, Spacelift plans it and waits for a human to confirm before anything touches AWS. That's the whole loop:

<div class="wiki-video-frame">
<video controls preload="metadata" poster="/wiki/media/spacelift-diagram-poster.jpg" width="728">
<source src="/wiki/media/spacelift-diagram-video.mp4" type="video/mp4">
Your browser doesn't support embedded video. <a href="/wiki/media/spacelift-diagram-video.mp4">Download the video</a> instead.
</video>
</div>

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id <stack-id></code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
instance_id = aws_instance.web.id
state = "stopped" # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:AI Agents]]

MediaWiki:Common.css

2026-08-21T18:41:26Z

Brett: Broad safety net: force sidebar columns transparent

MediaWiki:Common.css

2026-08-21T18:39:19Z

Brett: Fix white sticky header on scroll

MediaWiki:Common.css

2026-08-21T18:35:43Z

Brett: Fix white thumbnail image backgrounds, add ink-frame treatment

MediaWiki:Common.css

2026-08-21T17:57:22Z

Brett: Kill remaining white wrapper backgrounds

MediaWiki:Common.css

2026-08-21T17:32:08Z

Brett: Fix placeholder logo, overflow, leftover white

MediaWiki:Common.css

2026-08-21T17:24:14Z

Brett: Deep restyle: kill Vector white chrome, match site palette

MediaWiki:Common.css

2026-08-21T17:10:07Z

Brett: Fix logo image sizing

MediaWiki:Common.js

2026-08-21T17:10:06Z

Brett: Fix logo image sizing

MediaWiki:Common.js

2026-08-21T17:04:27Z

Brett: Inject matching masthead with hamburger

/* Inject a masthead matching brettfullmer.com's header, with a working hamburger menu. */
( function () {
var header = document.createElement( 'header' );
header.id = 'bf-masthead';
header.innerHTML =
'<div class="bf-wrap">' +
'<a class="bf-name" href="https://brettfullmer.com/"><img src="https://brettfullmer.com/favicon.svg" alt="">Brett Fullmer</a>' +
'<div class="bf-mobile-actions">' +
'<a class="bf-cta" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'<button class="bf-toggle" aria-label="Toggle menu" aria-expanded="false">' +
'<span></span><span></span><span></span>' +
'</button>' +
'</div>' +
'<nav class="bf-links" id="bf-nav-links">' +
'<a href="https://brettfullmer.com/#about">What I Do</a>' +
'<a href="https://brettfullmer.com/#experience">Experience</a>' +
'<a href="https://brettfullmer.com/#sabbatical">AI Lab</a>' +
'<a href="https://brettfullmer.com/blog/">Blog</a>' +
'<a href="/wiki/Main_Page" class="bf-current">Wiki</a>' +
'<a class="bf-cta bf-cta-desktop" href="https://linkedin.com/in/brettfullmer">LinkedIn</a>' +
'</nav>' +
'</div>';

document.body.insertBefore( header, document.body.firstChild );

var toggle = header.querySelector( '.bf-toggle' );
var links = header.querySelector( '.bf-links' );
toggle.addEventListener( 'click', function () {
var isOpen = links.classList.toggle( 'open' );
toggle.classList.toggle( 'open', isOpen );
toggle.setAttribute( 'aria-expanded', isOpen ? 'true' : 'false' );
} );
links.querySelectorAll( 'a' ).forEach( function ( a ) {
a.addEventListener( 'click', function () {
links.classList.remove( 'open' );
toggle.classList.remove( 'open' );
toggle.setAttribute( 'aria-expanded', 'false' );
} );
} );
}() );

MediaWiki:Common.css

2026-08-21T17:04:26Z

Brett: Match site header/branding

Main Page

2026-08-21T17:00:42Z

Brett: Add self-maintaining index via DynamicPageList4

[[File:Brett-cover-art.jpeg|thumb|right|220px|Brett Fullmer]]
Hi, I'm Brett Fullmer — a remote Technical Account Manager / Customer Success Manager with 20+ years in enterprise infrastructure and managed services. Long enough to have been the person a customer calls right after they've already tried turning it off and on again, and somehow still liked me afterward.

These days I'm doing something a little different. Since 2024 I've been heads-down in an independent AI lab, building LLM-powered automation and AI agent frameworks for technical support and customer engineering — the kind of tooling I wish had existed earlier in my career. I'm not here to tell you AI is going to replace your job. I'm here to tell you it replaced the boring 60% of mine, and I'm still gainfully employable, so everybody can relax.

Two decades of infrastructure experience, a career built on trust, and right now, a lab full of AWS servers I've built, broken, and rebuilt on purpose, in public, using Infrastructure as Code — because "trust me, it works" is not a deployment strategy.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line — not the one reading from a knowledge base article they've never actually run themselves.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein, which is more than I can say for most Terraform I've inherited from other humans. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) — real AWS Infrastructure as Code, not a sandbox with training wheels — exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan on a pitch deck.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success, Customer Engineering, or Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner — I've read that particular org chart before.

== Index ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer. This section is generated automatically from page categories, so it stays accurate as new pages get added — no stale link list to maintain by hand.

=== Start here ===

* [[Spacelift]] — how the AWS practice labs actually got built, gotchas included
* [[How to Use Spacelift]] — the simple, step-by-step version
* [[MAC]] — the AI agent doing the actual day-to-day work here

=== Infrastructure & AI ===

<DPL>
category = Infrastructure as Code
notpage = Main Page
ordermethod = title
mode = unordered
</DPL>

=== Everything, alphabetically ===

<DPL>
namespace =
notpage = Main Page
notpage = MediaWiki:Sidebar
ordermethod = title
mode = unordered
count = 100
</DPL>

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

[[Category:Technical Account Manager]]
[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]
[[Category:Enterprise Infrastructure]]
[[Category:AI Agents]]
[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:Remote Work]]

Spacelift

2026-08-21T16:49:10Z

Brett: Link the how-to guide

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[How to Use Spacelift]] for the step-by-step version, and [[MAC]], the agent that did most of the hands-on work.

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id <stack-id></code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
instance_id = aws_instance.web.id
state = "stopped" # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:AI Agents]]

How to Use Spacelift

2026-08-21T16:48:52Z

Brett: Write how-to guide with illustrations

[[File:Spacelift-howto-hero.jpeg|thumb|center|500px|Config in, plan reviewed, confirmed, applied.]]
A simple walkthrough of how infrastructure actually gets deployed with Spacelift — the same process used to build the [[Spacelift|labs documented here]]. Written for anyone who already knows what Infrastructure as Code is and wants to see how Spacelift specifically fits into that workflow. Seven steps, no step skipped, nothing applied without a human saying so.

== Step 1: Write your infrastructure as code ==

Describe what you want — a server, a network, a database — as config files (OpenTofu or Terraform) in a Git repository. This is the "shopping list," not the click-through-a-console approach. It's also the part that makes every future change reviewable, since it's just a diff in a file.

== Step 2: Create a Spacelift stack ==

Point Spacelift at that repository and branch. A "stack" is Spacelift's unit of infrastructure — one stack usually maps to one deployable piece of your system (a network, an app, a database tier).

== Step 3: Attach cloud credentials, scoped on purpose ==

Connect the stack to your cloud account. Worth doing deliberately here: automation/read-only access and actual deploy access don't have to be the same credential. Keeping them separate means a compromised or overly-curious tool can look, but can't touch.

== Step 4: Push a change ==

Commit and push. Spacelift picks it up automatically and runs a '''plan''' — a full preview of exactly what would change, added, or destroyed. Nothing has touched the real infrastructure yet.

== Step 5: Read the plan like it matters ==

[[File:Spacelift-howto-confirm.jpeg|thumb|right|280px|The gate that keeps a bad plan from ever reaching production.]]
This is the step people skip when they're in a hurry, and the step that saves you when you are. The plan shows every resource being created, changed, or destroyed — read it the way you'd read a contract before signing it.

== Step 6: Confirm ==

Only after a human clicks confirm does Spacelift actually apply anything to the real account. This is the whole point: plan and apply are two separate, deliberate actions, not one button that does both. It's the difference between "this happened" and "I meant for this to happen."

== Step 7: Check the run history any time ==

Every run — who triggered it, what changed, whether it was confirmed or rejected — stays in Spacelift's history. Weeks later, "why did this change" has an actual answer instead of a guess.

== Why it's worth the extra step ==

None of this is exotic. It's the boring, unglamorous discipline that turns "I hope this doesn't break something" into an actual guarantee — whether the thing pushing the change is a person or, as in [[MAC|this case]], an AI agent working with real credentials. The gate is the same either way, and that's exactly the point.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:Technical Account Manager]]

File:Spacelift-howto-hero.jpeg

2026-08-21T16:48:33Z

Brett: == Summary == How-to guide illustrations

== Summary ==
How-to guide illustrations

File:Spacelift-howto-confirm.jpeg

2026-08-21T16:48:33Z

Brett: == Summary == How-to guide illustrations

== Summary ==
How-to guide illustrations

Spacelift

2026-08-21T16:39:16Z

Brett: Add matching categories

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[MAC]], the agent that did most of the hands-on work.

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id <stack-id></code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
instance_id = aws_instance.web.id
state = "stopped" # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:AI Agents]]

Main Page

2026-08-21T16:38:51Z

Brett: Add humor, target keywords, add categories

[[File:Brett-cover-art.jpeg|thumb|right|220px|Brett Fullmer]]
Hi, I'm Brett Fullmer — a remote Technical Account Manager / Customer Success Manager with 20+ years in enterprise infrastructure and managed services. Long enough to have been the person a customer calls right after they've already tried turning it off and on again, and somehow still liked me afterward.

These days I'm doing something a little different. Since 2024 I've been heads-down in an independent AI lab, building LLM-powered automation and AI agent frameworks for technical support and customer engineering — the kind of tooling I wish had existed earlier in my career. I'm not here to tell you AI is going to replace your job. I'm here to tell you it replaced the boring 60% of mine, and I'm still gainfully employable, so everybody can relax.

Two decades of infrastructure experience, a career built on trust, and right now, a lab full of AWS servers I've built, broken, and rebuilt on purpose, in public, using Infrastructure as Code — because "trust me, it works" is not a deployment strategy.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line — not the one reading from a knowledge base article they've never actually run themselves.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein, which is more than I can say for most Terraform I've inherited from other humans. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) — real AWS Infrastructure as Code, not a sandbox with training wheels — exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan on a pitch deck.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success, Customer Engineering, or Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner — I've read that particular org chart before.

== This wiki ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post. Think of it as the deleted scenes, minus the awkward director's commentary.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

[[Category:Technical Account Manager]]
[[Category:Customer Success Manager]]
[[Category:Customer Engineering]]
[[Category:Enterprise Infrastructure]]
[[Category:AI Agents]]
[[Category:Infrastructure as Code]]
[[Category:AWS]]
[[Category:Remote Work]]

Main Page

2026-08-21T16:33:50Z

Brett: Write introduction

[[File:Brett-cover-art.jpeg|thumb|right|220px|Brett Fullmer]]
Hi, I'm Brett Fullmer. Twenty-plus years in enterprise infrastructure and managed services taught me one thing that never stopped being true: technical authority means nothing if you're not human first. I've spent a career being the person a customer calls when something real is actually on the line — not the one reading from a knowledge base article.

These days I'm doing something a little different. Since 2024 I've been heads-down in an independent AI lab, building the kind of LLM-powered automation and agent frameworks I wish had existed earlier in my career — not as a side hobby, but as a hands-on way of proving what responsible AI-directed work actually looks like when someone competent is watching. I'm not interested in vibes-based AI hype. I'm interested in whether it holds up when it's pointed at something real, and what has to be true for that to be safe.

So that's the introduction: two decades of infrastructure experience, a career built on trust, and right now, a lab full of servers I've built, broken, and rebuilt on purpose, in public, so I can show the work instead of just claiming it.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line. That background is the foundation everything else here is built on top of.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success / Customer Engineering / Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner.

== This wiki ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

Main Page

2026-08-21T16:31:14Z

Brett: Swap to MAD-cover-art style portrait

[[File:Brett-cover-art.jpeg|thumb|right|220px|Brett Fullmer]]
'''Brett Fullmer''' is a Technical Account Manager with 20+ years in enterprise infrastructure and managed services — technical authority, human first.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line. That background is the foundation everything else here is built on top of.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success / Customer Engineering / Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner.

== This wiki ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

File:Brett-cover-art.jpeg

2026-08-21T16:30:13Z

Brett: == Summary == MAD-cover-art style portrait

== Summary ==
MAD-cover-art style portrait

Spacelift

2026-08-21T16:29:13Z

Brett: Document how the lab was built

This page documents how the [[Main Page|AWS/IaC practice lab]] actually got built — two working environments, run through Spacelift, with real gotchas along the way. See also: [[MAC]], the agent that did most of the hands-on work.

== Why it exists ==

Practice, ahead of an interview with Spacelift itself. The goal wasn't a tutorial-grade demo — it was a real AWS account, real infrastructure, real failure modes, so the mistakes happened here instead of live.

== The two labs ==

=== Orbit Labs (two-stack) ===

Two independent Spacelift stacks, one Git repo each, linked by a Spacelift-level stack dependency rather than a Terraform data source:

* '''Networking stack''' — VPC (<code>10.0.0.0/16</code>), one public subnet, an internet gateway, and a public route table. Outputs <code>subnet_id</code>.
* '''App stack''' — consumes <code>subnet_id</code> as <code>var.subnet_id</code>. Builds a key pair, two security groups (web: 80/443/22 from an admin-only CIDR; db: 3306 from the web SG only), a pinned-AMI web fleet across prod/dev/test environments, and one dedicated database instance.

The app stack cannot plan until the networking stack has applied and produced that output — enforced on Spacelift's Dependencies tab, not just documented convention.

=== Pulsar (single-instance) ===

A simpler, single self-contained stack built later specifically to avoid the stack-dependency wiring above for quick experiments: one VPC, one t3.micro/t3.small instance, no cross-stack linkage. 443 open to the world by design (for testing real internet-facing TLS); 22 restricted to an admin IP. An Elastic IP keeps the address stable across stop/start and resize cycles.

== Build order ==

# Push the networking/base stack first; wait for <code>FINISHED</code>.
# Push the app stack; it fails outright with a missing-variable error if pushed before the dependency exists.
# Poll with <code>spacectl</code>, not the browser — the web UI lags behind real state.
# Pull outputs (<code>spacectl stack outputs --id <stack-id></code>) for live IPs once finished.

== What actually broke ==

* '''AMI drift wiped a fleet.''' A <code>data "aws_ami" { most_recent = true }</code> lookup meant a routine, unrelated push replaced the entire web fleet the moment AWS published a new image — new IPs, and any state that only lived on local disk was gone. Fix: pin the AMI as a fixed-default variable, bump it deliberately.
* '''The AWS console reads a literal <code>Name</code> tag.''' Resources tagged with lowercase <code>name</code> are valid but invisible in the console's Name column. Every resource needs <code>Name = "..."</code>, capital N.
* '''Deleting a stack doesn't clean up its dependency link.''' Emptying the networking stack's config to tear it down left the app stack's dependency reference dangling — the next run on either stack failed with a vague missing-input error until the link was removed and, later, explicitly re-added before rebuilding.
* '''Free-tier restrictions fail mid-operation.''' Requesting a <code>t3.medium</code> resize got rejected by a <code>FreeTierRestrictionError</code> — but only after AWS had already stopped the instance to attempt the resize, leaving it stopped (and, without an Elastic IP already attached, on a fresh IP).
* '''Uploaded-file PHP execution was silently broken.''' Because the vhost proxies every <code>*.php</code> request straight to PHP-FPM at the server-config level, MediaWiki's and WordPress's default "disable script execution in the uploads directory" <code>.htaccess</code> protection didn't actually apply — confirmed by dropping a harmless <code>.php</code> test file in <code>wp-content/uploads/</code> and watching it execute. Fixed with an explicit <code>SetHandler none</code> + <code>Require all denied</code> override in both upload directories.

== The pattern that's worth keeping ==

Instance power state as a declarative resource, not a manual CLI step:

<pre>
resource "aws_ec2_instance_state" "web" {
instance_id = aws_instance.web.id
state = "stopped" # flip to "running", push, confirm
}
</pre>

Flip the string, push, Spacelift applies it. No compute billing while stopped; the Elastic IP means the address survives the whole cycle.

== Why Spacelift specifically ==

* Plan and apply are structurally separate, with a mandatory human confirm gate before anything touches AWS.
* Stack dependencies are a first-class, enforced object — not a README instruction to run things in order.
* Full run history via <code>spacectl stack run list</code> — every change, when, and why, queryable later.
* The automation API key is scoped read-only by design; it hard-fails on anything that tries to trigger a deploy. Read access for tooling and write access for a human are two separate credentials.

That last point is the one that actually matters most: it's the reason handing real, live infrastructure work to [[MAC]] was something to trust rather than something to worry about.

[[Category:AWS Lab]]

Main Page

2026-08-21T16:19:57Z

Brett: Add portrait

[[File:Brett-portrait.jpeg|thumb|right|220px|Brett Fullmer]]
'''Brett Fullmer''' is a Technical Account Manager with 20+ years in enterprise infrastructure and managed services — technical authority, human first.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line. That background is the foundation everything else here is built on top of.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success / Customer Engineering / Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner.

== This wiki ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

File:Brett-portrait.jpeg

2026-08-21T16:19:17Z

Brett: == Summary == Portrait for Main Page

== Summary ==
Portrait for Main Page

Main Page

2026-08-21T16:13:00Z

Brett: Rewrite Main Page to be about Brett

'''Brett Fullmer''' is a Technical Account Manager with 20+ years in enterprise infrastructure and managed services — technical authority, human first.

== Background ==

Two decades in enterprise infrastructure and managed services, the kind of work that means being the person a customer trusts when something real is on the line. That background is the foundation everything else here is built on top of.

== Currently ==

Since 2024, heads-down in an independent AI lab: building LLM-powered automation and agent frameworks aimed at technical support and enterprise account management. [[MAC]] is the AI agent that does the actual day-to-day work — infrastructure, research, writing — under real guardrails rather than free rein. The [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar) exist to prove that "AI-directed infrastructure" can be a trustworthy way of working, not just a slogan.

The site's own tagline puts it plainly: '''building with AI, unapologetically.'''

== What I'm looking for ==

Remote Customer Success / Customer Engineering / Technical Account Manager roles. Not interested in big-tech-branded vendor TAM positions, even through a reseller or partner.

== This wiki ==

If [https://brettfullmer.com the site] tells the story and [https://brettfullmer.com/blog the blog] writes it up, this is the reference layer — build notes, gotchas, and the detail that's too dry or too "living document" for a blog post.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]

Main Page

2026-08-21T16:06:57Z

Brett: Write Main Page

'''Welcome to the Fullmer Wiki.'''

If [https://brettfullmer.com the site] is where I tell the story and [https://brettfullmer.com/blog the blog] is where I write it up, this is where I keep the reference material — the stuff that's too detailed, too dry, or too much of a living document to fit a blog post.

== What's here ==

* '''AWS / IaC Lab''' — build notes, gotchas, and teardown/rebuild procedures for the [[Spacelift]] + OpenTofu practice labs (Orbit Labs, Pulsar).
* '''MAC''' — what the AI agent I work with actually has access to, how it operates, and the guardrails (Spacelift's plan/confirm gate, scoped credentials) that make handing it real infrastructure something I'm comfortable with.
* '''Job Search Reference''' — companies, roles, and research notes from the current search.

== Status ==

Brand new as of August 2026. Mostly empty right now — this grows as I actually do the work, not ahead of it.

== Elsewhere ==

* [https://brettfullmer.com Home]
* [https://brettfullmer.com/blog The Fullmer Frequency (blog)]
* [https://linkedin.com/in/brettfullmer LinkedIn]