Replace SVG diagrams with PNG

pages/agent/v3.md

@@ -16,7 +16,7 @@ You (or your organization) need one or more running agents to run builds, but on
 
 The agent works by polling Buildkite's agent API over HTTPS. There is no need to forward ports or provide incoming firewall access, and the agents can be run across any number of machines and networks.
 
-<%= image "buildkite-hybrid-architecture.svg", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
+<%= image "buildkite-hybrid-architecture.png", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
 
 The agent starts by registering itself with Buildkite, and once registered it's placed into your organization's agents pool. The agent periodically polls Buildkite looking for new work, waiting to accept an available job.
 

pages/agent/v3/elastic_ci_aws/elastic_ci_stack_overview.md

@@ -7,7 +7,7 @@ The Buildkite Elastic CI Stack for AWS gives you a private, autoscaling
 
 This diagram illustrates a standard deployment of Elastic CI Stack for AWS.
 
-<%= image "buildkite-elastic-ci-stack-on-aws-architecture.svg", alt: "Elastic CI Stack for AWS Architecture Diagram" %>
+<%= image "buildkite-elastic-ci-stack-on-aws-architecture.png", alt: "Elastic CI Stack for AWS Architecture Diagram" %>
 
 ## Features
 

pages/pipelines/defining_steps.md

@@ -113,7 +113,7 @@ When a step is run by an agent, it will be run with a clean checkout of the pipe
 
 When you run a pipeline, a build is created. The following diagram shows you how builds progress from start to end.
 
-<%= image "build-states.svg", size: "900x615", alt: "Build state diagram" %>
+<%= image "build-states.png", alt: "Build state diagram" %>
 
 
 <%= render_markdown partial: 'pipelines/build_states' %>
@@ -122,7 +122,7 @@ When you run a pipeline, a build is created. The following diagram shows you how
 
 When you run a pipeline, a build is created. Each of the steps in the pipeline ends up as a job in the build, which then get distributed to available agents. Job states have a similar flow to [build states](#build-states) but with a few extra states. The following diagram shows you how jobs progress from start to end.
 
-<%= image "job-states.svg", size: "1482x690", alt: "Job state diagram" %>
+<%= image "job-states.png", alt: "Job state diagram" %>
 
 As well as the states shown in the diagram, the following progressions can occur:
 

pages/pipelines/migrate_from_jenkins.md

@@ -34,7 +34,7 @@ The program that executes work is called an _agent_ in Buildkite. An agent is a
 
 The following diagram shows the split in Buildkite between the SaaS platform and the agents running on your infrastructure.
 
-<%= image "buildkite-hybrid-architecture.svg", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
+<%= image "buildkite-hybrid-architecture.png", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
 
 The diagram shows that Buildkite provides a web interface, handles integrations with third-party tools, and offers APIs and webhooks. By design, sensitive data, such as source code and secrets, remain within your environment and are not seen by Buildkite. This decoupling provides flexibility, as you can scale the build agents independently while Buildkite manages the coordination, scheduling, and web interface.
 

pages/tutorials/getting_started.md

@@ -28,7 +28,7 @@ Buildkite uses a hybrid model consisting of the following:
 
 The following diagram shows the split in Buildkite between the SaaS platform and the agents running on your infrastructure.
 
-<%= image "buildkite-hybrid-architecture.svg", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
+<%= image "buildkite-hybrid-architecture.png", alt: "Shows the hybrid architecture combining a SaaS platform with your infrastructure" %>
 
 The diagram shows that Buildkite provides a web interface, handles integrations with third-party tools, and offers APIs and webhooks. By design, sensitive data, such as source code and secrets, remain within your environment and are not seen by Buildkite. This decoupling provides flexibility and security as you maintain control over the build environment and agent scaling while Buildkite manages the coordination, scheduling, and web interface.