diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 0000000..70460ce
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,9 @@
+# Please see the documentation for all configuration options:
+# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
+
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: daily
diff --git a/.github/styles/Google/Headings.yml b/.github/styles/Google/Headings.yml
index a533013..e34d001 100644
--- a/.github/styles/Google/Headings.yml
+++ b/.github/styles/Google/Headings.yml
@@ -1,15 +1,14 @@
 extends: capitalization
 message: "'%s' should use sentence-style capitalization."
-link: 'https://developers.google.com/style/capitalization#capitalization-in-titles-and-headings'
+link: "https://developers.google.com/style/capitalization#capitalization-in-titles-and-headings"
 level: warning
 scope: heading
 match: $sentence
 indicators:
-  - ':'
+  - ":"
 exceptions:
   - Azure
   - CLI
-  - Code
   - Cosmos
   - Docker
   - Emmet
diff --git a/content/2022-11-16.md b/content/2022-11-16.md
index 790ffc3..a09ff1d 100644
--- a/content/2022-11-16.md
+++ b/content/2022-11-16.md
@@ -16,7 +16,7 @@ tags = ["brew"]
 
 Backups are critical, not matter what is being backed up. On MacOS the most popular package manager is [Homebrew](https://brew.sh/). With a few simple commands backing up and restoring a brew environment is a breeze.
 
-![gif](/static/tapes/brew-bundle.gif)
+![gif](/tapes/brew-bundle.gif)
 
 ```bash
 # backup, defaults to `Brewfile`
diff --git a/content/2023-12-07.md b/content/2023-12-07.md
new file mode 100644
index 0000000..6cdb8df
--- /dev/null
+++ b/content/2023-12-07.md
@@ -0,0 +1,107 @@
++++
+title = "DevX Gon' Give It To Ya"
+description = "Speeding up dev cycles on Zarf packages with `zarf dev deploy`"
+slug = "devx-gon-give-it"
+date = 2023-12-07
+draft = false
+
+[taxonomies]
+tags = ["zarf","devx"]
+
+[extra]
+meta = [
+    {property = "og:image", content = "https://og.razzle.cloud/og?title=DevX%20Gon'%20Give%20It%20To%20Ya"},
+]
++++
+
+> **TL;DR** The newly introduced `zarf dev deploy` can greatly speed up Zarf package dev cycles.
+>
+> I adapted much of this article from the [ADR](https://github.com/defenseunicorns/zarf/blob/main/adr/0022-dev-cmd.md) I wrote for `zarf dev` and `zarf dev deploy`
+
+<!-- more -->
+
+## Who cares?
+
+Well, [Jeff](https://www.linkedin.com/in/jeffsmccoy/) told me my job was on the line if I didn't do it, so that was reason enough for me to implement. _(for legal reasons that was a joke)_
+
+But in all seriousness anyone who develops [Zarf](https://github.com/defenseunicorns/zarf) packages should take note and try out this pretty slick feature.
+
+## If it ain't broke make it better
+
+![it can be better](https://media1.tenor.com/m/SMkXNFf_aIkAAAAC/max-lord-maxwell-lord.gif)
+
+The Zarf package debug/development feedback loop varies significantly depending on the encountered bug or added feature. Generally though, the cycle follows:
+
+1. Create/edit a `zarf.yaml` file and components
+2. Build the package w/ `zarf package create`
+3. Debug any _create_ errors and resolve by editing the `zarf.yaml` and repeating step 2
+4. Run `zarf init` against a fresh running cluster
+5. Deploy the local tarball w/ `zarf package deploy <tb>`
+6. Debug any _deploy_ errors and resolve by editing `zarf.yaml` and repeating steps 2 or 5
+
+If there are deployment errors, the common pattern is to reset the cluster (ex: `k3d cluster delete && k3d cluster create`) and repeat steps 4-6. Re-initializing the cluster, recreating the package, and redeploying the package is tedious and time consuming (~1.5 minutes on my beast of a dev machine); especially when the package is large or the change was small.
+
+So what's the bottleneck?
+
+The foundation of Zarf is turning technologies geared towards fully connected environments and making them air-gap native.
+
+As such, `zarf package create` is designed around a zero knowledge approach. It **can't** make any assumptions about the connected nature of the environment it's being created for (unless `.metadata.yolo == true`). This means that any dependencies referenced (whether they are container images, `git` repos, `helm` charts, files, etc...) **must** be retrieved/assembled _each_ and _every_ run.
+
+There already exists the concept of [`YOLO` mode](https://github.com/defenseunicorns/zarf/blob/main/adr/0010-yolo-mode.md), which can build + deploy a package without the need for `zarf init`, and builds without fetching certain heavy dependencies (like container images). However, `YOLO` mode isn't exposed via CLI flags, and is meant to develop and deploy packages in fully connected environments.
+
+## The new hotness
+
+Starting with Zarf `v0.32.0`, the `zarf dev deploy` command is available.
+
+> `zarf dev deploy` has a number of flags that closely match a combination of flags from `zarf package create` and `zarf package deploy`, but there are some differences (for example `--set` is split between `--create-set` and `--deploy-set`)
+>
+> To view all the flags run `zarf dev deploy --help`
+
+`zarf dev deploy` combines the lifecycle of `zarf package create` and `zarf package deploy` into one command. It also has the following features:
+
+- No `--confirm` or interactive prompts (it's dev mode after all)
+- Only builds & deploys components that _will_ be deployed (contrasting with a traditional `zarf package create` which builds _all_ components each time)
+- Can create & deploy in either YOLO mode (default) or prod mode (similar to a regular `zarf package create`)
+
+If the current goal is to test whether or not a package's Helm charts, Kustomizations, K8s manifests, etc... work properly; a normal `zarf dev deploy` will suffice.
+
+If the current goal is to more closely replicate a full `zarf package create && zarf package deploy`: `zarf dev deploy --no-yolo` is more the move.
+
+> NOTE:
+>
+> In order for `zarf dev deploy --no-yolo` to function, `zarf init` must be run first.
+> There may be an introduction of `zarf dev init` to speed this process up, but for now this is the current strategy. The speed benefits of `zarf dev deploy` combined with it being marked as [`[beta]`](https://docs.zarf.dev/docs/roadmap#beta) lead the team to believe it was better to get the feature out the door and into the hands of users rather than wait for the _entire_ devx experience to be revamped.
+
+## What changed
+
+In order to enable `zarf dev deploy` to be possible, there was some cleanup that had to happen to some lifecycle helper functions during `create`.
+
+As a result, `create` has been distilled down into three high level stages (each with their own sub helpers).
+
+- `load`
+  - Read the `zarf.yaml` into memory
+  - Resolve component `import`s + apply `flavor` + `only` filtering
+  - Apply `PKG_TMPL` variables to the `zarf.yaml`
+  - Process `extension`s
+- `assemble`
+  - Run `onCreate` actions before + after assembling all components + dependencies into a fresh `/tmp/zarf-*` directory
+  - Pull images + OCI artifacts
+  - Generate SBOMs
+- `output`
+  - Tarball up each `component`s dependency directory
+  - Generate package `checksums.txt`
+  - Generate build metadata + write the in-memory `zarf.yaml` to temp
+  - Sign the `zarf.yaml` (if provided a key)
+  - Publish to an OCI registry or create a local tarball
+
+For `zarf dev deploy`, only `load` and `assemble` are run. Using existing `create` logic, pulling `images` and generating SBOMs is controlled via the `--no-yolo` flag.
+
+In contrast to `zarf package create`, after the `load` function has run, `zarf dev deploy` uses a helper function from `deploy` to filter down the components even more than `--flavor` and `--arch`.
+
+The results of these lifecycle changes results in a command that's **blazingly** fast at taking a `zarf.yaml` and applying it to a local cluster. See for yourself:
+
+![Demo GIF](/tapes/zarf-dev-deploy.gif)
+
+## Takeaway
+
+The introduction of `zarf dev deploy` in Zarf version 0.32.0+ marks a significant leap in the development workflow for Zarf packages. This streamlined command combines the creation and deployment process, offering a faster and more efficient way to test and deploy packages in both YOLO and production modes.
diff --git a/scripts/new.mjs b/scripts/new.mjs
index b46597a..8c03068 100755
--- a/scripts/new.mjs
+++ b/scripts/new.mjs
@@ -21,9 +21,14 @@ draft = true
 
 [taxonomies]
 tags = ${JSON.stringify(tags, null, 0)}
+
+[extra]
+meta = [
+    {property = "og:image", content = "https://og.razzle.cloud/og?title=${encodeURI(title)}"},
+]
 +++
 
-> tldr;
+> **TL;DR**
 
 <!-- more -->
 
diff --git a/static/tapes/zarf-dev-deploy.gif b/static/tapes/zarf-dev-deploy.gif
new file mode 100644
index 0000000..f4e1fb7
Binary files /dev/null and b/static/tapes/zarf-dev-deploy.gif differ
diff --git a/static/tapes/zarf-dev-deploy.tape b/static/tapes/zarf-dev-deploy.tape
new file mode 100644
index 0000000..3377ca9
--- /dev/null
+++ b/static/tapes/zarf-dev-deploy.tape
@@ -0,0 +1,17 @@
+Output zarf-dev-deploy.gif
+
+Set Shell "bash"
+Set FontSize 24
+Set Width 1900
+Set Height 1100
+Set TypingSpeed 50ms
+Set Framerate 25
+
+Type "# Blink and you'll miss it" Sleep 1s Ctrl+C Enter
+Type "# Package `create`s are near instantaneous during `dev deploy`" Sleep 2s Ctrl+C Enter
+Type "zarf dev deploy examples/dos-games" Sleep 500ms Enter
+Sleep 11s
+Type "# Now let's re-deploy and see how fast it is" Sleep 2s Ctrl+C Enter
+Type "zarf dev deploy examples/dos-games" Sleep 500ms Enter
+Sleep 5s
+Type "# Pretty fast right?" Sleep 2s Ctrl+C Enter