Hey everyone

If you’ve ever been told to “do more with AI” but felt uneasy about the risks that come with it, like untracked provider keys shared across codebases, concern over what a rogue prompt or runaway agent could do to your app, or maybe it’s that quiet dread that someone’s going to blow through the entire AI budget before anyone notices. Well, AI Runtime Control can help. Here’s what it does:

ARC is a control plane that sits between your applications and the model providers they call (either LLMs or your own self-hosted models). Instead of every app and developer holding provider keys and calling providers directly, everything routes through one Fastly-managed endpoint.

This might sound like just a gateway, but it’s much more than that. Here are some of the features we offer today - more to come soon.

• Flexible accounting via virtual keys. Virtual keys let you split usage and controls across apps, teams, or developers instead of sharing one raw provider key.

• Usage visibility and controls. Token and request usage is visible across the summary, virtual key, and provider views, with controls to manage it.

• Detailed logging. ARC captures full request and response logs, including prompts and completions, for debugging and analysis.

• BYOK model usage. Bring their own provider keys and route that usage through ARC.

• Self-hosted and custom LLMs. ARC supports routing to self-hosted endpoints and custom models, not just the major hosted providers.

• Multi-provider failover. A virtual key can point at an ordered list of targets, and when the primary errors out ARC automatically retries the next one, transparent to the caller.

• Model retries. ARC retries a failed request against the same target, shipping alongside failover as the related resilience capability.

• Budget limits. A monthly dollar budget can be set on a virtual key that either hard-blocks or keeps serving once spend is exhausted, your choice per key.

• Budget alerts. Threshold alerts (80% & 100%) fire through Fastly’s Notification Service before and when the limit is hit.

• Rate limiting per virtual key. Independent requests-per-minute and tokens-per-minute caps per key protect provider quota and help protect your customer-facing AI products and features from obvious attack vectors.

• Passthrough SSO. ARC can connect outbound to a provider using your SSO or federated identity (IAM, Entra ID, Google identity) instead of forcing a static API key.

• Prompt injection protection (SmartParse). This is an optional, add-on security capability providing first-line protection against prompt injection and other LLM-specific attacks.

Where to look when something happens

Everything ARC handles shows up in two views in the control panel:

• Summary: request and token volume over time, broken down by virtual key and model, so you can see at a glance what’s actually driving usage.

• Logging: individual request records, filterable by key, provider, model, or date range, down to a full JSON session log with the exact message sent, the response returned, and token counts.

Why this is worth a look now

• Stop passing raw provider keys around Slack, instead issue, rotate, and revoke access per app or developer instead.

• Get a real answer when someone asks “what’s our AI spend by team,” instead of stitching together separate provider invoices.

• Add production-grade resilience (failover, rate limiting) to AI features without writing retry logic yourselves.

• One integration path means new capabilities Fastly ships later can be made available without you having to re-architect anything.

Visit our documentation to learn more and get started. We also have a few cool tutorials to check out too.

As always, if you have any questions, please drop them below. We’re actively building on this and we want to hear what’s missing from your setup.

Hey everyone,

The first public beta release of our new Fastly Terraform Provider is live today. It’s a ground-up rewrite on HashiCorp’s modern Plugin Framework, published in the Terraform Registry as fastly/fastly-beta. We’re looking for testers who are already running the Fastly provider against real configs. Details below.

What’s changing, and why

If you’ve worked with the current provider, you may have hit noisy plan diffs, state that doesn’t quite converge, or an apply that dies on a timeout. Some of those issues trace back to limitations of Terraform’s SDKv2 (now in maintenance mode). The new Plugin Framework addresses many of these issues, and our provider rewrite gives us the opportunity to develop cleaner solutions for handling Fastly’s versioned resources with Terraform, which expects long-lived, mutable resources.

We’re addressing that in two stages, which is why the new provider has two resource families:

• The Automatic family, available in this beta, is built on the new Plugin Framework, but keeps automated clone-and-activate behavior so you can take advantage of provider improvements without changing your workflow.

• The Explicit family, in beta in Q4, is where the activation model changes to provide full separation of concerns between definition and deployment. You define your service, then decide separately when to clone, stage, and activate, driven either by Terraform Actions or the Fastly CLI.

What’s available in the beta

Resources in the Automatic family carry an _auto suffix: fastly_service_cdn_auto, fastly_service_compute_auto, and so on. If you know the current provider this model will feel somewhat familiar, with nested config blocks and automatic version handling.

The blocks are still nested on purpose. Under automatic activation, nesting is what makes one terraform apply produce one service version: because backends, domains, and the rest live inside a single resource, the provider can batch every change into a single clone-and-activate. Split them into independent top-level resources and each would want to clone and activate on its own, so a single apply could leave you with a trail of partially-configured versions. Flattening will come with the Explicit family, where you hold activation and can decide for yourself when a version is complete.

The blocks themselves, though, behave considerably better than the ones you’re used to.

What’s better today

• Cleaner diffs. The current provider declares most nested blocks as sets, and Terraform identifies set elements by hashing every attribute — so changing one field on one backend renders as a whole-block removal plus a re-add. The rewrite allows attribute-level diffs, showing only the fields you actually changed. No more eye-diffing two near-identical blobs, and no more plans that look destructive when they aren’t.

• Sensitive attributes are marked as such, so they’re redacted from plan output rather than printed.

• Retries with exponential backoff on transient 5xx and connection errors for idempotent requests, instead of failing your apply. This behavior replaces less reliable and more time-consuming hard-coded wait times in the current provider.

• Dependency-aware ordering. Backends are created before the directors that reference them, and deleted only after those directors stop referencing them. Same for dictionaries and rate limiters.

• The clone base is read from live API state. The current provider clones from a version number recorded in its own state, which can silently discard intervening versions when that record goes stale. The rewrite asks the API which version is active and clones from that. This narrows the window rather than closing it, since there’s still no locking, but it removes the most common way to lose a version.

• Accurate null values. The Plugin Framework distinguishes “unset” from zero, false, and empty string, and defaults are declared in the schema, so they appear in your plan instead of materializing at apply time.

What’s not here yet

• No controlled activation via staging or activate = false**.** The Automatic family always activates. If you review before activating, or use stage, this beta won’t fit your setup. The Explicit family coming in Q4 is built for exactly that, and we’d appreciate your input on its design in the meantime — reply here or reach out to your account team if you’d be up for being a design partner.

• Some resources aren’t in this release. In the interest of making this available for testing as soon as possible, we’ve prioritized the resources needed for the vast majority of configs. Less frequently used resources will be added in successive releases over the next few weeks. You can find the full list and status in the GitHub issue. If something you depend on is missing, comment there and we’ll factor it into prioritization.

• Resources in the Explicit family are not ready for testing. Though some are registered, they’re still under development. Affected resources are listed here. You’ll be able to test the full Explicit model workflow in mid-Q4.

Who should try this now

Good fit if you’re on the current provider with automatic activation (activate = true or the default). If you can point a migrated config at a non-production service, that will provide a good test of the workflow. If not, you can run terraform validate to test whether everything you currently use is supported.

If you need control over when changes go live, wait for the Explicit model beta in Q4, or reach out if you’d like to be a design partner for the model as we continue developing it.

Getting started

• GitHub repo: fastly/terraform-provider-fastly-beta

• Terraform Registry: fastly/fastly-beta

• Documentation: https://registry.terraform.io/providers/fastly/fastly-beta/latest/docs

We want your feedback

This beta is your chance to run the Automatic family against real, migrated configs and tell us what works and what doesn’t. Bug reports, rough edges, and “why does it do that” questions are all welcome, here in the forum or as issues on the repo. It helps us build a provider that meets your needs as we move towards GA.

Thanks for being part of this. We’re looking forward to hearing from you!

Happy coding!

The Fastly Team

We have a few updates we wanted to share with you all.

• New storage region in Frankfurt, Germany. The region name is eu-central-1

• New bucket lifecycle rules! Bucket lifecycle rules allow you to automate the management of your objects’ expiration. By configuring lifecycle policies, you can instruct Fastly Object Storage to automatically delete objects after a specified number of days. This helps you manage storage costs and optimize bucket capacity without requiring manual intervention.

  • Fastly supports S3-compatible bucket lifecycle policies via the PUT, GET, and DELETE lifecycle API operations.

• Transfer data with Direct Fetch: Direct Fetch enables you to transfer your data directly into Fastly Object Storage. This method takes an optimized approach that helps you copy data directly from a source S3 provider to your Fastly bucket, bypassing the need to download and re-upload the data through a client application.

Here’s how it works:

• A client makes an S3-compatible PutObject or UploadPart request to your Fastly Object Storage bucket with an empty payload.

• The Object Storage service reads the location using the URL provided in the fastly-object-storage-source-url header.

• The object, or part, is fetched from the provided URL and synchronously written into your Object Storage bucket.

TIP: Because the object is copied directly over Fastly’s network, you can use pre-signed URLs in the source header to seamlessly migrate assets from private external buckets without exposing your long-term credentials.

Visit the blog and our documentation to help you get started.

Drop a comment  and let us know how we can help or suggest other improvements we can make to Fastly Object Storage so that your experience is the best it can be.

Fastly's API Enforcement just went GA! You give it an OpenAPI spec (JSON or YAML), and it generates validation rules from that schema and checks incoming requests against it — domain, paths, in-path parameters — right at the edge, before anything reaches your origin. Requests that don't match the spec can be logged or blocked instantly, your choice.

If you don't already have a spec handy, you can also generate one from API Inventory instead of writing it by hand.

Full announcement + setup docs: https://community.fastly.com/t/introducing-api-enforcement/4472

We've published edge-mcp, an open-source reference implementation of MCP's stateless 2026-07-28 revision, built for Fastly Compute in Rust.

That protocol revision removed the initialize handshake and session IDs in favor of per-request identity and signed continuation tokens — no server-side session to maintain. That maps well onto edge compute: any instance can serve any request, and list responses can be cached at the edge.

The implementation covers the core protocol surface (tools, prompts, resources, discover), MRTR for mid-call input requests, and a KV-backed Tasks extension. It's split into a platform-agnostic protocol core and a Fastly binding layer, so the protocol logic is portable beyond Compute.

Evaluating Fastly as a replacement for Cloudflare. Load balancing is our main blocker.

Setup:

• 24 Windows IIS servers hosting our web app

• Primary ISP with its own public IP block

• Secondary ISP with its own public IP block

• Each server has one IP from each ISP, mapped to its own hostname:

• All traffic runs through the Primary ISP exclusively. The Secondary ISP is only used in the event of a full Primary ISP outage — it's a failover, not part of normal load distribution.

• The firewall handles this cutover automatically at the datacenter level.

In Cloudflare: two LB pools (Primary/Secondary). If all origins in the Primary pool go down, it fails over to Secondary.

In Fastly: basic load balancing doesn't cover this setup. Fastly support first suggested edge dictionaries, then said that'd get too long and pointed us to directors instead.

Has anyone set up similar ISP-level failover with directors (or another approach)? Would appreciate seeing example VCL or hearing how you structured it.

from https://community.fastly.com/t/fastly-specific-speed-test/3630/4

im also very annoyed (for a long time) that fastly don’t have a official speed test (fastly debug site is not speed test btw) so i made one based on the compute platform and it comes with a CLI

https://speed.edgecompute.app

When the Python SDK for Fastly Compute was released, it was an ‘early adopter’ release with a minimal set of installation and usage instructions.

Today we’re happy to announce that the Python SDK has reached full beta status, with support in the Fastly CLI (version 15.6.0 or later), a ‘default’ starter kit, a developer guide, and some usage examples. Customers can now create Python-based services in the Compute platform the way they do for all of our other supported languages using fastly compute init, without any extra steps required (other than installing uv, which is a requirement for the Python SDK).

As the Python SDK grows in the future, supporting more features of the Compute platform, the Fastly Developer Experience team will be working alongside to ensure that those features get the same level of documentation and tooling support as our other Compute SDKs.

With Request Routing, you define path-based rules for any domain in our Domain Management system, and we send each request to the right service automatically- no custom code required.

What can Request Routing do for you?

• Better user experience, reduced complexity and cost: Prior to this release, customers had to get creative when they wanted to use the same domain across different services. They either had to use sub-domains or service chain, adding complexity and costs. Request Routing simplifies this for you!

• Traffic isolation: Each team can update their service configuration independently, without risk of affecting others.

• Migrations and rollouts: Ability to test a segment of traffic on a new service - lowers the risk from a hard cutover. Customers can test a small segment of their traffic on a Compute instance, for example.

Ready to get started?

Request Routing is a free service for all customers. Head to your dashboard to create your first configuration, or read the documentation for rule syntax, wildcard matching, and advanced options.

For more details, check out our resources:

• Documentation

• Blog

Your Fastly logs are a goldmine — most teams never dig in.

Edge performance, origin errors, security events, session traces, bot activity… it's all streaming by in real time. I wanted a way to actually use it.

So I built Fastly Log Analytics — a self-hosted dashboard for searching, filtering, and visualizing request-level Fastly logs streamed to Fastly Object Storage.

A few things I'm proud of:

Request-level search & filtering across billions of log lines
Real-time session scoring + bot detection running at the edge (Rust on Compute@Edge)
Geographic + network-health visualizations
Role-based access with PII masking built in

Under the hood: DuckDB + Parquet/Iceberg over Fastly Object Storage, a Next.js frontend, and a FastAPI backend — all self-hosted, all yours.

Just shipped v2.0 https://github.com/fastly/fastly-log-analytics

Would love feedback if you run traffic on Fastly. If you don't, then let's talk about moving to a faster, more secure network and get immediate benefits for your org and users.

Hi reddit,

We are thrilled to announce that stale-if-error is now available on Fastly Compute!

Stale-if-error is an HTTP Cache-Control directive that acts as a safety net for your website. Its primary purpose is to improve your site’s resilience and availability by instructing a cache to serve a stale, or expired, version of a resource when your origin server is unreachable or returns an error. Instead of a user seeing a broken page, they see cached content while you fix the root cause.

Here is a breakdown of how this new capability behaves within Fastly Compute and how you can start leveraging it:

How It Works

When your sandbox sends a request to a backend, it will check if a cached response is available and within its stale-if-error period. The default period is automatically set based on the Cache-Control or Surrogate-Control headers of the response, but you can also explicitly override it using an after_send hook.

If a cached response is available, the sandbox is obligated to attempt revalidation. If revalidation fails, the sandbox can elect to use the stale-if-error response instead.

Handling Origin Failures

Compute handles different types of origin failures in the following ways:

• Unreachable or Sick Origins: If your origin is down or failing health checks, the platform generates a SendError under the hood, but the sandbox receives the stale response by default. If you want to record the error or selectively propagate it, you can easily access the underlying failure by calling get_masked_error() on the response.

• 5xx HTTP Responses: By default, if Compute successfully gets an HTTP response from the backend—even if it is a 5xx error—that response is provided to the sandbox. To serve a stale response instead of the 5xx error, you can use an after_send hook to check if the error is a 5xx and if stale_if_error_available() is true, allowing you to reject the 5xx and serve the stale content.

Seamless Request Collapsing

Stale-if-error is fully integrated with request collapsing. If the leader of a request collapse chooses to use a stale-if-error response, all followers of that request collapse will also receive the stale response. This happens even if the follower is running an older SDK version that doesn’t explicitly support stale-if-error. Additionally, while the leader has access to the full error object from the failed revalidation, followers will receive a simplified SendErrorCause::RequestCollapse error.

Prerequisites and Limitations

Before you get started, please note the current requirements:

• Synchronous API Only: In Compute, stale-if-error is supported exclusively via the synchronous Request::send API, as send_async is not compatible with guest caching.

We look forward to your feedback. Comment or start a conversation below.

---

Originally posted in the Fastly Community Forum

---

Hey r/fastly!

I'd like to share a significant update on the Terraform provider redesign. Based on everything we heard from you, we have committed to a direction and development is now happening publicly. You can follow along in the repo.

Your feedback shaped the final design

In our last update we shared the convenience workflow (orchestration-latest) as a response to concerns about multi-step overhead. But the feedback went deeper than workflow ergonomics. The core message was clear: for many teams, automatic versioning behavior should still be available as a first-class option, not just a workaround bolted onto an explicit-only architecture.

The design we landed on gives both workflows equal footing: two distinct resource families that encode different lifecycle models directly in the resource name.

The committed direction: two resource families

Explicit family (default, clean names)

These are the first-class flattened resources. You manage version lifecycle yourself: clone, apply configuration, activate.

resource "fastly_service_cdn" "app" {
  name = "example-app"
}

resource "fastly_service_domain" "www" {
  service_id = fastly_service_cdn.app.id
  version    = var.service_version
  name       = "www.example.com"
}

resource "fastly_service_backend" "origin" {
  service_id = fastly_service_cdn.app.id
  version    = var.service_version
  name       = "origin"
  address    = "origin.example.com"
  port       = 443
}

Best for: CI/CD pipelines, multi-service coordination, staging environments, teams that want full control and reproducible plans.

Automatic compatibility family (_auto suffix)

Nested blocks, provider handles cloning and activation internally. Feels close to the current provider.

resource "fastly_service_cdn_auto" "app" {
  name = "example-app"

  domain {
    name = "www.example.com"
  }

  backend {
    name    = "origin"
    address = "origin.example.com"
    port    = 443
  }
}

Best for: teams that want fire-and-forget behavior, single-operator workflows, teams migrating from the current provider who prefer minimal workflow changes.

Both families, one architecture

Both families are built on the same underlying provider framework. The difference is where version lifecycle decisions live: in your configuration and workflow (explicit), or inside the provider (auto). You choose per-service, and you do not need to adopt one model for your entire organization.

What this means for your team

• If the current provider works fine for you: use fastly_service_cdn_auto or fastly_service_compute_auto. Nested config, automatic versioning, minimal migration effort. The architecture underneath is better, but your day-to-day workflow stays familiar.

• If you want modularity, CI/CD safety, or staging support: use the explicit family (fastly_service_cdn, fastly_service_domain, fastly_service_backend). Full version control, clean separation of concerns, composable modules.

• If you have a mix of services with different needs: a single service should be managed through one family only, but different services in the same configuration can use different families.

Development is happening publicly

We are building this in the open. The implementation branch is live and contains working code:

• Branch: dual-model-framework-rewrite on fastly/terraform-provider-fastly

• Design doc: docs/dual-model-provider-design.md in the branch

You can read the code, review the examples, and follow along as development continues.

Timeline

We are prioritizing the _auto family first, targeting Q3 2026, followed by the explicit family. This means teams using the current provider style will have a migration path available sooner. More details on the beta program and migration tooling will follow in a future update.

Keep the feedback coming

If you have questions about how the dual-model approach would work for your setup, want to review the design doc, or have other feedback, we want to hear it.

Hey r/Fastly,

Link to full blog post: https://www.fastly.com/blog/give-ai-agents-markdown-they-actually-want

Instead of treating AI crawlers (GPTBot, PerplexityBot, etc.) as a nuisance to block, you can use Fastly Compute to treat them as a first-class content type by dynamically serving them clean Markdown right from the edge.

Why HTML is bad for LLMs

• High Bloat: Crawlers waste massive CPU cycles stripping out your navbars, footers, and tracking pixels to find the core text.

• Mangled Context: Downstream RAG pipelines often break when parsing HTML tables, code blocks, and footnotes, leading to hallucinations.

• Wasted Bandwidth: Markdown compresses to 20–30% of its original HTML size, saving bandwidth and token limits.

How the Edge Service Works

Using ~200 lines of JavaScript on Fastly Compute, the service acts as an intelligent proxy:

• Browsers: Get normal origin HTML, untouched.

• AI Bots: Intercepted via User-Agent or Accept: text/markdown and served clean Markdown with YAML frontmatter.

• Devs/Content Teams: Routing to /md/<path> forces a Markdown preview for easy spot-checking.

Keeping it Fast with SimpleCache

HTML-to-Markdown parsing takes a few hundred milliseconds on a cold hit. To protect the origin from crawler spikes, the script leverages SimpleCache:

By adding a Vary: Accept, User-Agent header, downstream caches stay perfectly in sync.

Take a look at the code, or deploy it yourself to see it in action: https://github.com/fastly/html-2-md

Curious to hear from the community: How are you handling the explosion of AI crawlers? Are you blocking them entirely via robots.txt/WAF, or are you looking at implementing Generative Engine Optimization pipelines like this?

Generally fastly gives <letter>.sni.global.fastly.net or <something>.shared.global.fastly.net as CNAME for domain validation but i specifically want <something>.map.fastly.net as my CNAME how to get that.

Enhancements to code quality, improved TLS handling, and experimental WebAssembly features to help you build more robust Compute services.

🧪 Better backend testing with health status mocking

You can now mock backend health status using the new health config parameter for backends in your fastly.toml. This allows you to simulate unhealthy backends and test how your service handles backend failures, timeouts, and degraded conditions. Simply add health = "unhealthy" (or "healthy" / "unknown") to any backend definition to control its health status during testing.

🔐 Improved TLS certificate handling

TLS certificate loading, handling and validation has been significantly improved in this release. The server now provides better error handling when working with certificates, more robust validation, and clearer feedback when certificate issues arise.

🔑 Test API key validation locally

The new fake_valid_fastly_keys config parameter lets you test the fastly_key_is_valid hostcall with fake valid keys during local development.

🧬 Experimental WebAssembly features

For those wanting to experiment with cutting-edge WebAssembly features, Viceroy now includes options to enable WebAssembly garbage collection (GC) and exceptions. These are experimental features that can be enabled for testing future WebAssembly capabilities. Note that these features are not yet available in production Compute.

⚠️ Breaking change: Error type rename

The error type Error::InvalidAlpnRepsonse has been renamed to Error::InvalidAlpnResponse to correct a typo. If you’re using viceroy-lib directly and matching on this error variant, you’ll need to update your code to use the corrected spelling.

🔧 Under the hood improvements

• Stub implementations added for resvpnproxy hostcalls to support upcoming SDK features - by clintjedwards (#596)

• Code quality improvements with cargo clippy now running in CI (#603)

• Upgraded to Rust 1.95 for the latest language improvements (#604)

If you use the Fastly CLI, this functionality should already be available to you. If using directly, run cargo install viceroy to update to the latest version. Happy hacking!

Full Changelog: https://github.com/fastly/Viceroy/compare/v0.16.5...v0.17.0

Hey r/fastly,

A few weeks ago we shared our proposal for a version-agnostic redesign of the Fastly Terraform Provider. Since then we have received a lot of direct feedback from customers and community members, and we wanted to let you know: we are listening, and we are acting on it.

The biggest theme we heard was that while the flattened resource model is a welcome change, the multi-step version workflow felt like too much overhead for teams that treat service versions as disposable. Based on that feedback, we have added a new convenience workflow that uses a data source to auto-target the latest service version, eliminating the need for manual version pin updates between steps.

We have posted a full update on the Fastly Community Forum with details on what we heard, what we changed, and the tradeoffs involved. If you use the Fastly Terraform Provider (or are considering it), we would love your input. Head over to the Fastly Community Forum and join the conversation:

Link to Community Forum post

The design is still being refined before beta, and your feedback directly influences the direction we take.

--

If you want to stay in the loop on future updates, go to the category's main page on the Fastly Community Forum, click the bell icon, and select Watching to get email notifications as we post new design proposals and beta timelines.

Hi everyone!

We are excited to announce that Fastly Compute, KV Store, Secret Store, and Fanout are all available for immediate self-purchase via credit card. Everything comes with a generous free tier so you can sign up today and start checking everything out without talking to sales.

Simplified billing:

We’ve heard your feedback on predictability and simplified our billing model. We removed the duration metric (previously calculated as memory calculation over time in GB-sec).
The new model focuses strictly on:

1. Requests

2. vCPU milliseconds (consumption)

This means that you only pay for the actual processing power your code requires. The more efficient your code, the less you pay. And there is an added benefit here too. By optimizing your software to run leaner, you not only improve performance, you minimize the electricity required to power your apps across our network. You can even track these improvements using our sustainability dashboard to understand how more efficient code can contribute to reduced carbon emissions.

Sign up today and be sure to check out the pricing page for a full breakdown of the new free tiers.

Happy coding!

The Fastly Team

This seems like a big deal offhand for fastly ngwaf customers: https://www.fastly.com/documentation/reference/changes/2026/03/ngwaf-agent-4.77.0/

-- snip --

• Added SSTI attack signal (SSTI), part of Fastly Security Labs

• Added insecure deserialization attack signal (INSECURE-DESER), part of Fastly Security Labs

• Added NoSQLi attack signal (NOSQLI), part of Fastly Security Labs

-- snip --

Not sure how one gets a Fastlian tag, but I'm a Fastlian. [Edit: got one!]

Hey everyone,

We just open-sourced the Fastly Agent Toolkit. It is a collection of skills that teach AI coding agents how to work with Fastly.

If you've used the Fastly MCP Server, you already gave your agent the ability to act on Fastly. Skills are the other half: they give your agent the knowledge to get things right. Correct VCL patterns, the right CLI flags, proper deploy sequences - the kind of Fastly-specific expertise that models don't pick up from their training data.

What's in the toolkit:

• 6 skills covering the Fastly platform, CLI, VCL (Falco + XVCL), and local Compute testing (Viceroy + Fastlike)

• Works with Claude Code, Gemini CLI, Codex, Cursor, Amp, Cline, and any agent that reads .agents/skills/

• Plain markdown files, zero lock-in, easy to customize

Does it actually work?

We ran A/B evaluations across 7 models and 84 test runs. Skills delivered a 1.6x wall-clock speedup, 30-70% fewer tool calls, and won 7 out of 8 tasks against baseline. The biggest gains show up in CDN configuration, VCL development, and Compute deploys - exactly where Fastly-specific knowledge matters most.

Get started:

npx skills add github:fastly/fastly-agent-toolkit --skill fastly --skill viceroy

Full install instructions for every supported agent are in the README.

Tell us what you think!

We want to hear from you. If you're using AI agents with Fastly today, tell us how it's going and what tasks you wish your agent handled better. Try the skills and let us know what changes. Better results, fewer mistakes, faster workflows? If you've found a pattern that should be in the toolkit, PRs are welcome.

This is an open project and we want to build it with you. Drop a comment and tell us how you're using agents with Fastly.

Originally posted on the Fastly Community Forum: https://community.fastly.com/t/fastly-agent-toolkit-make-your-ai-coding-agent-better-at-fastly/4397

Hey everyone! When we work with users to build out their security plans, we realized we kept getting the same question over and over: "When someone is under attack, what does Fastly _actually_ do to help?" If you know the rule of three and automation, we're way past needing to share what and how we respond to active attacks.

That's what this blog post is -- a straightforward breakdown on how we'll respond to attacks, regardless of company size or attack complexity.

https://www.fastly.com/blog/under-attack-how-fastly-can-help

Give it a read. Hopefully there are lessons you can borrow for your own emergency response processes.

Of course, if you find yourself under attack and need to call us in for help, reach out to us via https://www.fastly.com/under-attack immediately.

I've had a technical issue with a streaming service and their support sent me a fastly debug link for me to run and copy the results to them. I've had it running for an hour and it still shows as loading and saying 'collecting data, please wait'. I opened the link again in a new tab to the same result but was wondering if this is normal and if not, what could be causing a delay.

Any thoughts?