statelyai · davidkpiano · Dec 22, 2025
diff --git a/blog/2019-11-13-no-disabling-a-button-is-not-app-logic/index.mdx b/blog/2019-11-13-no-disabling-a-button-is-not-app-logic/index.mdx
@@ -468,7 +468,7 @@ Don’t worry; we’re not actually executing any side-effects inside of this ma
 
 Furthermore, I can copy-paste this exact machine and [visualize it in XState Viz](https://xstate.js.org/viz):
 
-![Visualization of dog fetching machine](https://thepracticaldev.s3.amazonaws.com/i/hnsqk07cxbygbjo0h07j.png)
+![Visualization of dog fetching machine](https://res.cloudinary.com/practicaldev/image/fetch/s--sSFyyRFI--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/hnsqk07cxbygbjo0h07j.png)
 
 [View this viz on xstate.js.org/viz](https://xstate.js.org/viz/?gist=414c0e4c40dab1dc80c9218f85605a24)
 

diff --git a/blog/2019-12-09-xstate-version-47-and-the-future/index.mdx b/blog/2019-12-09-xstate-version-47-and-the-future/index.mdx
@@ -69,7 +69,7 @@ const machine = Machine({
 
 And it also makes it possible to directly copy-paste this machine code into a visualizer, like [XState Viz](https://xstate.js.org/viz), and visualize it, like was done at the end of the [No, disabling a button is not app logic](https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i) article:
 
-![State machine visualization on XState Viz](https://thepracticaldev.s3.amazonaws.com/i/218tb91ltxrnv988owz0.png)
+![State machine visualization on XState Viz](https://res.cloudinary.com/practicaldev/image/fetch/s--o5PbZ3py--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/218tb91ltxrnv988owz0.png)
 [View this viz on XState Viz](https://xstate.js.org/viz/?gist=414c0e4c40dab1dc80c9218f85605a24)
 
 Then there are **statecharts**, which are an extension of finite state machines created by [David Harel in 1989 (read the paper 📑)](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf). Statecharts offer many improvements and mitigate many issues of using flat finite state machines, such as:
@@ -133,7 +133,7 @@ if (state.matches('success')) {
 
 In 4.7, XState allows you to [represent your states with Typestates](https://xstate.js.org/docs/guides/typescript.html#typestates) so that you can tell the compiler that you know how the `context` should be in any given state:
 
-![GIF showing that the optional user object will be defined in the success state](https://thepracticaldev.s3.amazonaws.com/i/64d42j77op89yta9gbi8.gif)
+![GIF showing that the optional user object will be defined in the success state](https://res.cloudinary.com/practicaldev/image/fetch/s--GakogjRY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/64d42j77op89yta9gbi8.gif)
 
 This is very useful and improves the developer experience, but should be used as a strong guide, and not as a guarantee. It works by using [discriminated unions in TypeScript](https://basarat.gitbooks.io/typescript/docs/types/discriminated-unions.html) to define your states, but the way it is implemented requires TypeScript version 3.7 and higher. There’s still some quirks to work out, as we’re basically trying to trick TypeScript into knowing some extra information about our state machines that is otherwise difficult/impossible to infer in a statically typed language. (Maybe one day JavaScript will have a dependently-typed flavor.)
 

diff --git a/blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code/index.mdx b/blog/2020-07-27-state-machines-how-to-stop-making-horcruxes-in-your-code/index.mdx
@@ -97,11 +97,11 @@ I’d been using [XState](https://github.com/davidkpiano/xstate), and read that
 
 It produces clickable visualisations which you can share and walk through. For instance, the modal reducer above could be expressed in [this statechart](https://xstate.js.org/viz/?gist=56c56d2be397c4d5bea934c6d89e788d).
 
-![A statechart describing a modal which opens and closes](https://dev-to-uploads.s3.amazonaws.com/i/2lb0ctiu7s207t9w44mg.png)
+![A statechart describing a modal which opens and closes](https://res.cloudinary.com/practicaldev/image/fetch/s--XmLhsdr5--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/2lb0ctiu7s207t9w44mg.png)
 
 I knew that if I wasn’t careful, I’d end up with 25-30 horcruxes under my belt, logic carried in dozens of event handlers. So I wrote the machine in XState. I even wrote a VSCode extension so I could have the visualiser inline as I went along. Here’s what I ended up with:
 
-![An XState diagram of my video chat app](https://dev-to-uploads.s3.amazonaws.com/i/33vxe2bcsxn8uvfzlgva.png)
+![An XState diagram of my video chat app](https://res.cloudinary.com/practicaldev/image/fetch/s--oY3xYHhl--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/33vxe2bcsxn8uvfzlgva.png)
 
 Every part of this crazy complex app can now be visualised. I can see which conditions lead to which states. I can which actions are called on which events.
 

diff --git a/blog/2021-01-20-you-dont-need-a-library-for-state-machines/index.mdx b/blog/2021-01-20-you-dont-need-a-library-for-state-machines/index.mdx
@@ -33,7 +33,7 @@ If you’re unfamiliar with [finite state machines (FSMs)](https://en.wikipedia.
 - **Events**, which represent something that happened that can change state
 - **Transitions**, which represent how the state can change and what actions are executed when an event is received
 
-![States, events, and transitions](https://dev-to-uploads.s3.amazonaws.com/i/7ri5sbbrufj26cq3u026.png)
+![States, events, and transitions](https://res.cloudinary.com/practicaldev/image/fetch/s--NRBTk8Po--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/i/7ri5sbbrufj26cq3u026.png)
 
 Anything that can be described as changes in state over time due to events, from component-specific logic to application flows and even the orchestration of multiple services can be described with state machines, to some extent.
 

diff --git a/docs/machine-restore.mdx b/docs/machine-restore.mdx
@@ -21,7 +21,7 @@ But as you can see in the GIF below, we’ve introduced new error banners to sho
 If you lose connectivity, we’ll show the error banner saying, “You are offline, so we can’t save your machine; we will try our best to store a local copy you can restore later.”
 So feel free to keep editing; you can restore your work the next time you visit this machine on the same device.
 
-![Santa’s delivery state machine shows an error while trying to edit offline.](./assets/recovery_offline_error.gif)
+![Santa’s delivery state machine shows an error while trying to edit offline.](/recovery_offline_error.gif)
 
 ### How to restore
 
@@ -39,7 +39,7 @@ Now you have two options:
 You can see this in action using our example from above.
 When I return to the Studio, I can restore the changes I did while offline. Christmas is saved.
 
-![Stately Studio shows an option to restore changes made to a machine while the user was offline.](./assets/recovery_restore_machine.gif)
+![Stately Studio shows an option to restore changes made to a machine while the user was offline.](/recovery_restore_machine.gif)
 
 :::info