Forem: Fastly

Transform web pages at the edge

Sue Smith — Mon, 03 Nov 2025 16:57:50 +0000

Edge computing apps allow you to enhance the behavior of a website by manipulating the request and response at the network edge, near the user. You can now transform your web page content at the Fastly edge more easily with the HTML Rewriter in your JavaScript Compute apps. Ideal for customizations like personalization and A/B testing, the rewriter uses familiar DOM manipulation patterns.

Let's run through how to switch up your page HTML with a Fastly Compute app in just a few steps.

Start a new project

In your terminal, create a new directory:

mkdir htmlrewrite && cd htmlrewrite

Initialize a new Compute app:

npx @fastly/cli compute init

Accept the defaults, choosing JavaScript and selecting the empty starter kit.

Enter project metadata

In your new project, open the package.json and change the Compute JS SDK dependency as follows:

"@fastly/js-compute": "^3.35.1"

Run npm install to get your environment ready.

In the fastly.toml file, add the details for the website you want to transform at the edge (changing the addresses to use your own or using the included demo site):

[local_server]

  [local_server.backends]

    [local_server.backends.website]
      override_host = "www.goldengirls.codes"
      url = "https://www.goldengirls.codes/"

[setup]

  [setup.backends]

    [setup.backends.website]
      address = "www.goldengirls.codes"

Write your logic

In src/index.js we'll be writing our Compute logic to transform the HTML at the edge.

Start by importing a couple of dependencies:

import { getGeolocationForIpAddress } from "fastly:geolocation";
import { HTMLRewritingStream } from 'fastly:html-rewriter';

We're going to build geolocation into our processing.

Inside the handleRequest function, add try catch blocks:

try {

  //rewriter processing here

} catch (error) {
  console.error(error);
  return new Response("Internal Server Error", { status: 500 });
}

Grab geolocation info

Inside the try block, let's first get some info from the request:

let ip = new URL(event.request.url).searchParams.get("ip") || event.client.address;
let geo = getGeolocationForIpAddress(ip);

We're going to use the time of day at the user location to tailor the display:

let displayTime = new Date().getHours();
let offset = geo.utc_offset;
displayTime += offset / 100;

let emoji =
  displayTime > 4 && displayTime < 12
    ? " 🌇"
    : displayTime >= 12 && displayTime < 18
    ? " 🏙️"
    : " 🌃";

We'll insert this daft emoji into the page to personalize it to the user.

Specify rewrite behavior

Still inside the try block, use an HTMLRewritingStream to specify what you want your Compute app to do to the HTML from your origin website. In this example we append the emoji to the h1 element and replace every second image with a different one – change yours to suit your website!

let transformer = new HTMLRewritingStream()
  .onElement("h1", (e) => e.append(emoji) )
  .onElement("div.code:nth-child(even) img", (e) =>
    e.setAttribute("src", "https://shadypinesmiami.github.io/sophia.jpg"));

You can use standard CSS selectors to indicate the elements you want to transform.

Fetch the response from the website specified as a backend in your toml and carry out the transformation on it:

let backendResponse = (
  await fetch("https://www.goldengirls.codes/", { backend: "website" })
).body.pipeThrough(transformer);

Finally, return the new response to the user:

return new Response(backendResponse, {
  status: 200,
  headers: new Headers({ "content-type": "text/html" }),
});

Your script should now look something like this:

/// <reference types="@fastly/js-compute" />

import { getGeolocationForIpAddress } from "fastly:geolocation";
import { HTMLRewritingStream } from "fastly:html-rewriter";

addEventListener("fetch", (event) => event.respondWith(handleRequest(event)));

async function handleRequest(event) {

  try {
    let ip =
      new URL(event.request.url).searchParams.get("ip") || event.client.address;
    let geo = getGeolocationForIpAddress(ip);

    let displayTime = new Date().getHours();
    let offset = geo.utc_offset;
    displayTime += offset / 100;

    let emoji =
      displayTime > 4 && displayTime < 12
        ? " 🌇"
        : displayTime >= 12 && displayTime < 18
        ? " 🏙️"
        : " 🌃";

    let transformer = new HTMLRewritingStream()
      .onElement("h1", (e) => e.append(emoji) )
      .onElement("div.code:nth-child(even) img", (e) =>
        e.setAttribute("src", "https://shadypinesmiami.github.io/sophia.jpg")
      );

    let backendResponse = (
      await fetch("https://www.goldengirls.codes/", { backend: "website" })
    ).body.pipeThrough(transformer);

    return new Response(backendResponse, {
      status: 200,
      headers: new Headers({ "content-type": "text/html" }),
    });
  } catch (error) {
    console.error(error);
    return new Response("Internal Server Error", { status: 500 });
  }
}

Test your app

Time to run your app! In the terminal, enter the start command:

npm run start

With any luck you'll see a local address to try the app at.

You might notice that the time of day emoji doesn't actually match the time of day at your location.. 🤔 That's because your app is just running locally on your computer – you'll need to deploy it to the edge to see that functionality working reliably.

Deploy your app

Everything working the way you want it to? Great, time to deploy to Fastly.

Grab an API token from your account:

Go to Account > API tokens > Personal tokens
Click Create Token:
- Name: anything you like
- Type: Automation
- Role: Engineer
- Scope: Global (deselect the Read-only access box)
- Access: All services
- Expiration: Never expire
Copy the token value and save it on your computer

In your terminal, create a Fastly profile, entering the API token you copied from your account:

fastly profile create

Now you can go ahead and enter the deploy command:

npm run deploy

Accept the defaults and let the CLI create a new service for you, confirming the backend details from your toml. Once it's deployed, the output will include the address to try your new app at, which will end edgecompute.app:

Open your app in a browser to see the correct time of day indicator:

It is indeed afternoon where I am!

Keep going

Add more processing to your Compute app! You can use the HTML Rewriter to make all sorts of changes through DOM manipulation, like adding attributes to your elements to change the site behavior.

If you get stuck please feel free to post on the Fastly Community Forum. 🛟

Enabling developers in GitHub Codespaces

Sue Smith — Tue, 07 Oct 2025 14:09:43 +0000

Over the last few months I’ve been exploring GitHub codespaces for developer enablement. I needed to replace our Fastly onboarding projects that had been hosted on Glitch, and ideally wanted to avoid the need for learners to install local tooling or even sign up for an account before trying our Compute platform. In this post I’ll run through what I’ve discovered about using codespaces for dev product learning.

Here’s an overview of what our codespace projects do:

Install dependencies and automatically run an app
Open previews of the app UI in the codespace
Deploy apps at the click of a button using bash scripts
Hide UI elements to minimize distractions
Use an extension to show custom buttons in the editor for actions like splitting views, sharing app previews, opening the terminal, formatting code

This daft video runs through how they work:

Wait, what is a codespace?

A codespace is a web editing environment you can open in the browser from a GitHub repository. Codespaces use a version of the VS Code editor, so you can specify editor settings much like you would in a local VS Code installation. Using codespaces lets you carry out development activities without downloading or installing anything onto your local machine – it all happens in the cloud.

You can access codespaces from the homepage of a GitHub repo, using the Code button to open an environment for editing the codebase on a specific repo branch.

Edits made in a codespace are automatically kept for a limited period of time you can set in your GitHub account – you’ll receive a warning if a codespace is about to be deleted and you can export your changes to a branch if you aren’t ready to lose them.

Containers

A codespace runs in a Docker container, and you can specify requirements in the repo devcontainer.json file. I usually include system features like Node (mostly I’m targeting JavaScript projects in the Node ecosystem), but the codespace will guess some dependencies based on the repo content.

Here’s an example container spec I’m using for edge computing projects: ~learn-edge-computing/devcontainer.json

You can attach commands to container lifecycle events – these run when the codespace opens, so you can use them to carry out setup tasks and get the codespace in the state you want for your learners when they open the project. I’ve been using the updateContentCommand and postAttachCommand events to install NPM packages and run package.json scripts I want to execute straight away.

📚 The devcontainer metadata reference lists the options.

This is part of a container config I used for projects originally developed on Glitch that I’d exported to GitHub:

"updateContentCommand": "npm install",
"postAttachCommand": "npm run start || npx --yes serve"

Previews and ports

You can run apps “locally” in the codespace and they’ll be exposed through specific ports. With the Simple Browser you can automatically open these apps right inside the editor at an app.github.dev address. The PORTS area in the Terminal at the bottom of the editor provides access to port settings, so you can open previews, change visibility, and share URLs with collaborators.

In the container config, I include a section specifying that specific ports should automatically open in the preview. For my edge compute learning experience, it sets both the origin website and edge apps to open from their default ports, with custom labels making them more obvious to the learner:

"portsAttributes": {
  "3000": {
    "label": "🚧 Origin",
    "onAutoForward": "openPreview"
  },
  "7676": {
    "label": "🌎 Compute",
    "onAutoForward": "openPreview"
  }
}

I also use a custom 🔗 Share button to set a port to public and provide the URL so that the user can copy it to share with collaborators – they can see the preview as long as they’re logged into GitHub.

💡 If your project is a fully static site and doesn’t use a framework, you can still run a preview using npx serve.

Extensions

You can list required VS Code extensions in your codespace container config and they’ll automatically be installed when someone opens the project. I include ESLint because my projects typically use JavaScript, and the extension for custom buttons then runs the format command.

Custom buttons

I’ve found the VS Code Action Buttons extension extremely helpful when it comes to customizing the UI for my learning projects. The extension lets you specify buttons that appear along the bottom of the editor. Your buttons can call VS Code editor commands and CLI commands, so I use them to give users an easy way to toggle views, and run bash scripts or Terminal processes.

Here’s an excerpt of one of my button lists:

"actionButtons": {
  "commands": [
  {
    "name": "🌈 Prettify",
    "singleInstance": true,
    "useVsCodeApi": true,
    "command": "editor.action.formatDocument",
    "tooltip": "Tidy up your code"
  },
  {
    "name": "🚀 Publish",
    "singleInstance": true,
    "command": "bash helpers/publish.sh",
    "tooltip": "Publish your content to Fastly Compute"
    }
  ]
}

You can include whatever Terminal commands you need for your target frameworks – I tend to separate them into bash scripts so that the user can tweak them more readily if they like.

📋 Here are the commands you can run on button clicks: Built-in Commands

Bash scripts

With the projects I’m working on being experimental, I wanted users to be able to see and tailor the CLI code that automates processing. For that reason I included the bash scripts in a helpers folder, calling those scripts from the container config and button clicks. The Fastly CLI commands have a little bit of control flow complexity that really needs a lot of testing, so I need to be able to make changes easily.

Here’s a more basic bash script I use for projects users have imported (and I therefore don’t know for sure which scripts they have in their package.json):

# We're making some guesses about the package scripts lolol

if [ ! -f package.json ]; then
  printf "\n🤔 No package.json found – try the Open button instead!\n\n"
else 
  OOPS="\n🤬 hmm maybe check what's in your package.json scripts and try "npm run script-name"?\n\n"
  npm install || printf "${OOPS}"
  npm run start || printf "${OOPS}"
fi

I also use scripts like this to write out instructional information to the user in the Terminal.

Deployment

The Fastly projects support deployment to the edge, so I typically use a 🚀 Publish button that runs the Fastly CLI tooling and deploys the app. Here's publish script for our Compute Static Publisher: publish.sh

Codespaces make a great editing environment for simple static website projects, and you can publish from the editor, for example if you have a blog. You can deploy to GitHub Pages at the click of a button by including the gh-pages package in your project, and a script in your package.json, like this Vite example:

"scripts": {
    "start": "vite",
    "build": "vite build",
    "serve": "vite preview",
    "deploy": "gh-pages -d dist"
}

To publish using a button, just call the deploy command from the custom button extension covered above. I’m using this flow for my own blog and static site projects that I migrated from Glitch.

Environment variables

If your platform requires an API key, you can instruct users to acquire and add one inside the codespace. In the README I include links and steps for grabbing a Fastly API key and adding it using the command palette. When a user adds an environment variable, the codespace will prompt them to reload, which they’ll need to do in order to use the variable in subsequent commands.

File and feature visibility

You can specify settings for the VS Code editing experience in your container config just like you would in a local environment. I tend to hide some features to minimize distractions, like the minimap, and files / folders like node_modules, so that the learner can focus on the core parts of the project I’m trying to familiarize them with.

You can include these in the settings object in your container JSON:

"settings": {
    "files.exclude": {
        "package-lock.json": true,
        "node_modules/": true
    },
    "editor.minimap.enabled": false,
}

Source control

Although a codespace automatically stores your edits until it’s deleted, it’s a good idea to encourage users to regularly commit their changes to the underlying repo in case they lose them. You can do this in the Source Control area on the left.

Things can get a bit confusing depending on whether your users have started the codespace from your repo or from a fork of it – I encourage users to create their own fork so that it’s clearer where their changes should be saved.

🤔 Something that gets a bit messy with codespaces for dev product onboarding is that the flow seems to be primarily optimized for devs making contributions to a repo rather than forking it to make their own project. If you don’t plan to publish changes you want your users to be able to sync their forks with, you can use template repos instead. This is one place I’ve felt the tension of what I was able to support users to do on Glitch vs this workflow.

Optimizing your repos for codespaces

When you first open a codespace with a custom container config, it can be pretty slow to start up. You can reduce this with prebuilds that target specific regions you expect your users to be in. Although the free tier is generous, you might want to keep an eye on the costs for storage and compute associated with your codespaces, and definitely set spending limits in your GitHub account.

📝 Some of the setup for codespaces can translate to users cloning your repos locally and opening them in VS Code on their computers – this is something I want to explore soon, as well as supporting other web based VS Code environments.

Learn more

I found this post from Rizèl Scarlett super helpful when I was figuring out what I could do: How to run a frontend workshop in Codespaces 🙌

Some official docs:

Some of my codespace-optimized projects:

One I used for people migrating from Glitch: ~glitchy-editing
Publishing an 11ty blog to the edge: ~11ty-to-compute
Edge computing intro: ~learn-edge-computing

Develop an edge computing app in the browser

Sue Smith — Fri, 19 Sep 2025 09:22:44 +0000

When I try a new web technology, I really want to play around with it upfront before installing anything locally or setting up a developer environment. Over the last few months I’ve been exploring GitHub Codespaces for this purpose, working on a set of projects that guide you through building and deploying apps to the network edge straight from the browser. In this post I’ll introduce our new Fastly Compute learning experience that you can try out in seconds.

With a Compute app, you can enhance the user experience for a website at the edge. The app can manipulate the request from the user and the response from the origin website. You can write your code in various languages and the Fastly SDKs will compile it into Web Assembly (WASM) that can run at the edge, between your users and your website host. In this guide we’re writing our edge application logic in JavaScript.

Read on for a more detailed walkthrough of the flow but here’s the gist:

You fork a GitHub repo
Open your fork in a codespace
The app runs and automatically opens a preview
The project includes a sample origin website that runs too
You tweak the Compute app code and see the preview update as you work
When you’re ready, you grab a Fastly API key, copy it into your project, and publish

Fork the project

Getting your own app running takes a couple of clicks:

Sign into GitHub and visit the ~learn-edge-computing repo.
Fork the repo into your account (best to leave the name unchanged)
Open your fork in a codespace by clicking Code and creating a codespace on your main branch

When the codespace opens it’ll attempt to do a few things automatically:

Build, run, and open a preview for your example origin website
Build, run, and preview your initial Compute app
You’ll find some buttons along the bottom of the editor to make the process easier
- Use the 🔎 Split button to separate your preview from your code so that you can edit and see the results at the same time

Get to know your new app

🚧 Your project includes a demo origin website – the code for it is in the origin folder.

🌎 The logic for your Compute app is in the src folder. Check out the content of the index.js file.

In the Terminal area, select PORTS to see the origin and edge versions of your site – use the buttons to toggle between them in the preview. Check out the differences in functionality:

The style is different because the Compute app switches the stylesheet at the edge.
There’s a cookie written into the page that includes geolocation information passed in at the edge.
The ohno link returns a synthetic HTML page at the edge instead of a default server error.
The data link also returns a synthetic page instead of raw JSON.

Develop in the browser

Make a change to your Compute app. In the README you’ll find a suggested edit you can copy and paste right into the index.js file. With any luck your app will automatically rebuild and update in the preview. The edit adds information to the geolocation cookie indicating the time of day at the user location.

Note that the geolocation info won’t be accurate until you deploy to the edge, because your app is initially running “locally” inside the codespace which is running in a container hosted by GitHub.

Make changes to your origin app too in the origin folder, like changing the HTML and CSS.

You can share your draft app with collaborators using the 🔗 Share button at the bottom of the editor – they’ll just need to be signed into GitHub to see it.

Deploy to the edge

Sign up for a free Fastly account and grab an API key. Pop your key into your codespace with the name FASTLY_API_TOKEN.

Click the 🚀 Publish button at the bottom of the editor and follow the prompts. A few things will happen at this point:

The Fastly tooling will build your app and package it for deployment
It’ll create a new service in your Fastly account and upload the package
The scripts in the codespace will also deploy your origin website to a GitHub pages site for your repo
The GitHub pages site will be set as the origin for your Compute app

When everything’s ready, you’ll see an edgecompute.app address in the Terminal output. Go ahead and click it to check out your deployed app. How does it behave differently at the edge?

You can carry on making edits to your app and hit that 🚀 Publish button whenever you want to go live with them.

Remember to commit your changes to your fork of the GitHub repo if you want to keep them – use the Source Control area on the left of the codespace editor.

Keep going

Curious how the app works? Check out the helpers and .devcontainer folders!

Publish your website without a host

Sue Smith — Fri, 29 Aug 2025 10:17:26 +0000

When you use a CDN, cached copies of your website’s static assets are stored at the network edge for fast delivery to your visitors. Well, if your website is just those assets, why not just dump the whole thing at the edge and serve it directly from there instead of storing it on a web hosting service in the first place?

That's what the JavaScript Static Publisher for Fastly Compute does. It delivers your static site straight from the network edge using a serverless app to handle user requests, and an edge data store for your content. This kind of originless setup is well suited to generated static sites made up of HTML, CSS, and client side JavaScript, like blogs and react apps.

You can deploy existing sites to Fastly Compute using a few simple commands in your IDE. You can also create a new site, edit, and publish it without installing a thing on your computer by following a guided experience in a GitHub codespace – fork a demo project, open it in the browser, pop in an API key, and publish at the click of a button.

Try a simple static site

The ~website-to-compute project demonstrates how to publish a simple static site to the edge from a GitHub codespace.

The steps are in the repo README, here’s the TL;DR:

Fork the repo
Open your forked version for editing in the browser by clicking Code > Codespaces and creating a new codespace on your main branch
- The codespace config will run a few setup tasks when it first opens, it might take a couple of minutes
Your website preview will open in a tab – click the 🔎 Split button at the bottom to see the site side by side with your code
- Edit your site HTML and CSS! Your preview will update in the editor… 👀
- Share your draft site with collaborators by clicking 🔗 Share and copying the URL to your clipboard 📋
When you’re ready to publish to Fastly, sign up for an account and grab an API key, copying it into your codespace project
- Click the 🚀 Publish button along the bottom of the editor and follow the prompts
Your edgecompute.app address will appear in the terminal output
Make sure you save your edits to GitHub using the Source Control area on the left of the editor

Publish a project from your computer

If you already have a static site on your computer that you want to deploy, open it in an IDE.

Import the Static Publisher and pass it the root directory to scaffold a Compute app for your site:

npx @fastly/compute-js-static-publish@latest --root-dir=./_site  --kv-store-name=site-content

Set up dependencies:

cd compute-js && npm install

🧪 If you want to test your site locally before deploying, use npm run dev:publish and npm run dev:start then open it in the browser.

When you're ready to publish, grab a Fastly API key and set it as the value of the FASTLY_API_TOKEN environment variable.

Deploy your app:

npm run fastly:deploy

Open the edgecompute.app address in the terminal output – it won't show the content yet so don't worry if you see an error message. 😅

Publish your content to the KV Store:

npm run fastly:publish

Reload your edgecompute.app URL in the browser and with any luck your content will be there!

💡 Each time you have new content to publish, just run the fastly:publish command again.

📚 For more detail check out the tutorial.

Write and publish a blog from a codespace

The ~11ty-to-compute project publishes an Eleventy blog to the edge. You can draft new blog posts in the codespace and publish whenever you’re ready to share them with the world.

Check out the README for steps but here's the gist:

Fork the repo and open it in a codespace
Make changes and add blog posts
Grab a Fastly API key and add it in the codespace
Hit the 🚀 Publish button
Tell the world!

🔗 You can share your WIP blog posts for feedback from collaborators using the button at the bottom of the editor.

Next steps

Point your own domain at your new site
Learn about edge computing
Find out more about the JavaScript Static Publisher for Fastly Compute
Learn more about the publication flow in the static site publisher tutorial

🛟 Need help? Post on the Fastly Community forum!

Go OTEL Traces without the Globals

Grant Stephens — Thu, 29 May 2025 16:42:09 +0000

So I've been doing some work adding OTEL Traces to a Go service and have some notes. The service in question receives requests with trace headers, but also makes calls to other services and so should be injecting headers into subsequent requests too.

Firstly, the OTEL SDK is vast and takes a while to get your head around. Also, don't think you can just add one plugin for your HTTP router and be done- no such luck unfortunately. The SDK examples make use of global variables in various places which I really don't like. It actually feels like the Prometheus library from a few years ago. Anyway, this guide aims to avoid all the global variables and do things properly.

Setup

First things first- you're going to need a bunch of things that you instantiate and then pass around your app. I found that the 3 things I needed to pass around were the trace.Tracer, trace.TracerProvider and the propagation.TextMapPropagator.

The actual setup of each of those looks something like this:

...
otel.SetTracerProvider(noop.NewTracerProvider())
exporter, err := otlptracehttp.New(ctx)
r := resource.NewWithAttributes(
        semconv.SchemaURL,
        semconv.ServiceName("myService"),
        semconv.ServiceVersionKey.String("myVersion"),
    )
traceProvider := sdktrace.NewTracerProvider(
            sdktrace.WithBatcher(exporter),
            sdktrace.WithResource(r),
        )
tracer = traceProvider.Tracer(serviceName, trace.WithInstrumentationVersion(version))
textMapPropagator := propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.Baggage{})
...

What I then ended up doing is creating a struct with these things in it, plus some other observability items that all get passed around the app together which makes thing a lot cleaner

...
type O11y struct {
    Logger            *zerolog.Logger
    Metrics           *PromMetrics
    Tracer            trace.Tracer
    TraceProvider     trace.TracerProvider
    TextMapPropagator propagation.TextMapPropagator
}
...

This setup will use some environment variables to actually get the OTEL endpoint details. More detail on these can be found in the Environment Variable Specification. I like this pattern because an endpoint change can happen without an actual code change.

Now we're ready to start using these somewhere.

HTTP Server

Let's assume that you're using some kind of router package- I'd highly recommend that you then use the OTEL plugin for that package. You can find these plugins in the OTEL registry. In this case we're using the Julien Schmidt HTTPRouter and the plugin is from Splunk (nothing to do with Splunk logging mind you)- SplunkHTTPRouter.

The import path for this is a bit ridiculous, but I like to alias it to know that we're working with the trace version:

import (
...  
tracerouter "github.com/signalfx/splunk-otel-go/instrumentation/github.com/julienschmidt/httprouter/splunkhttprouter"
...
)

Now you actually need to make the router and add it to the server struct:

type Server struct {
    router *tracerouter.Router
    O11y
}

func New(o o11y.O11y) (*Server, error){
  ...
  s := &Server{
    router: tracerouter.New(
        otelhttp.WithTracerProvider(o.TraceProvider),
        otelhttp.WithPropagators(o.TextMapPropagator),
    ),
  }
  ...
  return s, nil
}

One small note here- you may want to exclude some paths from having any tracing on them. This is done as follows:

func OtelReqFilter(req *http.Request) bool {
    return req.URL.Path != "/healthcheck" &&
        req.URL.Path != "/metrics"
}

Then pass this in as another option in the tracerouter.New(), i.e.

...
router: tracerouter.New(
            otelhttp.WithFilter(tracer.OtelReqFilter),
...

Now we’re finally getting somewhere and can start adding some spans.

func (s *Server) myRouteHandler(w http.ResponseWriter, r *http.Request) {    
    span := trace.SpanFromContext(r.Context())
        defer span.End()
    ....
}

One more thing- error handling is a two step operation:

span.RecordError(err)
span.SetStatus(codes.Error, "some error")

Counter-intuitively the first operation does not actually set the span status.

HTTP Client

Now the client is a lot simpler, however because we are not using the global values in the OTEL SDK, we still need to pass in some things in order for trace headers to be injected on outgoing requests.

For each client that you create it has to look something like:

client := &http.Client{Transport: otelhttp.NewTransport(
http.DefaultTransport,
        otelhttp.WithTracerProvider(o.TraceProvider),
       otelhttp.WithPropagators(o.TextMapPropagator),
)}

Conclusion

Don't use global variables
Pass around the things your need- there are more than you think for OTEL.
Use environment variables to set OTEL parameters like sampling percentage. This means you don't need code changes to update them.
Filter out requests for /metrics and /healthchecks.

Building an actually secure MCP Server with Fastly Compute

Kay Sawada — Wed, 28 May 2025 03:56:39 +0000

We all know LLMs can do amazing things by now, but deploying them in the real world can mean running into real problems. For example, MCP (Model Context Protocol) is justifiably getting a lot of attention right now for the incredibly creative scenarios it can enable. But the security vulnerabilities MCP can expose should be a genuine nightmare for any organization, not to mention other major concerns like scaling or managing an MCP endpoint over time. But hey, good news: security, scaling, resiliency, and manageability is what we do! So we're going to show you how to use Fastly Compute to make an MCP Server that's ready for the real world — secure, scalable, and reliable.

What is MCP?

The Model Context Protocol (MCP) is an open protocol designed to standardize how applications provide essential context to Large Language Models (LLMs). MCP acts as a universal interface, enabling AI applications to seamlessly connect with diverse data sources.

MCP also provides the flexibility to switch between LLM providers and prioritizes data security within a user's infrastructure by employing a client-server architecture where applications (MCP Hosts) connect to data sources (Local Data Sources and Remote Services) through lightweight MCP Servers and Clients. This unified approach offers pre-built integrations, allowing developers to quickly leverage various data sources.

We'll cover how to build an MCP server using Fastly Compute, but if you're interested in accessing Fastly's platform API through MCP, the fastly-mcp-server package can help, and we'll be talking more about that in the future.

Why Fastly’s platform makes MCP run better

As an enterprise serverless architect, I often find myself advising customers on the best approach for their workloads, specifically whether they could benefit from edge computing. There are several factors I consider, such as the expected level of concurrency and potential spikes in the workload, and the need for low latency in user-facing applications. And, as you might have guessed, MCP, which we’ll delve into further in this article, is a really good example of a workload that benefits significantly from the unique design of Fastly’s platform and Fastly Compute. The following is a demonstration of the MCP Client in action.

You'll notice that the LLM agent is performing multiple concurrent calls to MCP tools, such as "GetHistoricalStats" and "GetServiceDetail." If you were responsible for running this MCP server, how much load would you estimate and how would you provision the server infrastructure? For a relatively new environment like MCP, having a massive and complex infrastructure isn't ideal. While serverless is convenient for starting small, you naturally need to avoid common issues like cold starts (without much hassle, of course). Given the possibility of spikes, where multiple users might simultaneously call the MCP tools, it's crucial to choose a scalable environment. Additionally, because communication often occurs via chat, it’s critical to keep response latency as low as possible.

A noteworthy advantage of using Fastly Compute for cases like this is that its WebAssembly-based runtime leverages isolation sandbox technology, enabling safer execution of code both locally and remotely. This means your MCP server is safer running on Fastly. As we’ve seen, Fastly Compute’s design addresses many of MCP’s inherent architectural weaknesses. In the following sections, I'll walk you through the specific process of deploying a remote MCP server using this platform.

How to build a remote MCP server with Fastly Compute

We'll start by deploying a Streamable HTTP endpoint that doesn't include legacy SSE endpoints. This can be easily accomplished using the following steps. Please note that you need to replace the API token in two places within the main.go file before publishing. (For information on obtaining your API token, refer to this guide document.)

$ git clone https://gist.github.com/d829a6a58ce359b1aa99ecae12ba79f1.git fastly-compute-mcp-server
$ cd fastly-compute-mcp-server
$ vi main.go # Replace __PUT_YOUR_FASTLY_API_TOKEN__ with your own TOKEN
$ fastly compute publish 
...
✓ Activating service (version 1)

Manage this service at:
    https://manage.fastly.com/configure/services/mMnYw4qeGq81xga89Mq8O0

View this service at:
    https://highly-proper-orange.edgecompute.app

During the publishing process, you'll be asked several questions. Answer "yes" to any y/n prompts, and for all other items, you can simply press “Enter” key to accept the default (empty) values. After a short while, you'll see a message indicating that your service is now available, as shown above.

Next, let's use the npx command to launch the MCP inspector verification tool and check if our deployed server is functioning correctly. Once the npx @modelcontextprotocol/inspector command completes successfully, access http://127.0.0.1:6274 to open the official tester interface. From the left sidebar, select "streamable http" as the connection type and enter the service address (https://*.edgecompute.app) shown as a result from the publish command.

When you see "Connected" below the Connect button in the left sidebar, it means the connection was successful. In the control pane on the right, click on the Tools tab and try actions like List Tools to test the functionality. This means you've successfully operated a remote MCP server that communicates using non-SSE Streamable-HTTP.

Adding support for legacy clients with SSE

As of this writing in May 2025, many MCP clients still do not support Streamable HTTP, and some remote servers only offer SSE transport. To ensure backward compatibility with these clients, we’ll take the MCP server we’ve created a step further by adding SSE support. (Note that in this sample, we will use Fanout for establishing SSE connections. This is a Fastly push messaging service that requires its own signup.)

First, create a new service following the same steps as before. However, this time when publishing, create two backends at the following stage of the screen. For the first backend, specify the address of *.edgecompute.app in the Domain field and name it "self". For the second backend, register api.fastly.com with the name "fastly" as shown below.

✓ Creating service

Domain: [put-your-favorite-name-here.edgecompute.app] 

Backend (hostname or IP address, or leave blank to stop adding backends): put-your-favorite-name-here.edgecompute.app
Backend port number: [443] 
Backend name: [backend_1] self

Backend (hostname or IP address, or leave blank to stop adding backends): api.fastly.com
Backend port number: [443] 
Backend name: [backend_2] fastly

Once you've published successfully, execute the command shown below as an additional step to enable Fanout. When you see the SUCCESS notification, your setup is ready to use.

$ fastly products --enable=fanout
SUCCESS: Successfully enabled product 'fanout'

Finally, configure your MCP client (like Claude Desktop or Cursor) to check functionality. For clients that natively support SSE, there's little difficulty—just follow the app's configuration instructions. In this case, we’ll set up LibreChat, an MCP client that only supports STDIO, as an example. (The following is an example of YAML configuration for LibreChat, but the method of executing the npx command is consistent for any client. Don't forget to use your edgecompute.app service URL when you configure "mcp-remote" command).

mcpServers:
  fastly-mcp-server:
    command: npx
    args:
      - -y
      - "mcp-remote"
      - https://highly-adequate-adder.edgecompute.app/sse
      - --transport
      - sse-only

As of May 2025, the mcp-remote package defaults to Streamable-HTTP connections unless you use the --transport sse-only option. To ensure a connection via SSE, you need to include this option.

When you launch LibreChat with this configuration, you'll see a screen like the one below. This completes the setup.

This sample shows an MCP tool that downloads the VCL from a Fastly VCL Service, but you can easily extend it with additional features. It’s important to note that Fanout's specification limits message size to about 64KB. So, when supporting legacy SSE, make sure the result messages from MCP tool calls don't become too large.

Conclusion: What’s next?

In this article, we've introduced how the flexible and efficient development environment of Fastly Compute simplifies the process of setting up a high-performance MCP server quickly. As a next step, I plan to explore building a more advanced server based on the OAuth specification. Stay tuned!

We would also love to hear how your organization is leveraging LLMs and AI, and how you are addressing the associated challenges. Please share your thoughts and join the community discussions. We welcome all kinds of feedback.

We should still teach coding

Sue Smith — Mon, 31 Mar 2025 13:28:22 +0000

Software written using generative AI is all over the web. Performance and security issues abound. Open source projects are being overwhelmed by bot traffic. There's a lot of harm being caused, but as an educator who cares about lowering barriers to software creation, I can't ignore the democratizing potential of these tools either.

In this post I’d like to explore the opportunities for learning that this paradigm shift presents – from how to make your projects more efficient and secure, to learning about the intellectual property and labor exploitation that might have gone into training the models you used.

Understanding incentives

One thing I have learned working in education is the value of accepting people’s motivations – having a goal that a skill will help you achieve is the most effective motivator for learning. Clearly many people are finding ways to use AI to help them achieve goals.

Motivations are determined by complex socioeconomic factors beyond our ability to reason away. Let’s instead keep the door to the good internet open by empowering people to make responsible choices, equipping them with knowledge of the technical systems they’re creating within.

Gen AI might help you spin up an MVP, but eventually you will have to dig into the code. You’ll either learn software engineering skills, or have to bring in the experts. Far from making engineers obsolete, I worry that less investment in these skills will make the barriers around the profession more extreme. A select few having insight into how critical systems work is not a future I’m enthusiastic about. Instead I’d like to find learning paths that these new ways of building software present.

The conditions for learning are in place

Projects developed using gen AI can support a range of good practices in education, including some key activities that we often neglect in both formal learning and the workplace:

Personalization: We can work on something meaningful to the learner rather than dragging them through a one-size-fits-all experience.
Fast feedback loops: Automation can fuel adaptive learning through short iterative cycles.
Reflection: Reflecting on an experience helps you internalize skills you’ve acquired and reapply them in different contexts.

Code generated using LLMs enables and requires these perhaps more than “traditional” ways of making software. There are also some coding pedagogy techniques that gen AI projects can lend themselves to:

Reading before writing – code comprehension is a crucial software engineering skill, consider an experienced engineer performing code reviews and mentoring junior teammates.
Starting from a functioning application instead of a blank slate.
Running an app to see what it does, then investigating how it did it.
Taking gradual ownership of a project by making a first edit, then turning it into something new.

⚠️ Generative AI is not an appropriate substitute for the many interpersonal aspects of effective learning IMO. “Mentoring” powered by biased LLM content is incredibly dangerous.

Encouraging inquiry and independent thought

I wonder about a gen AI coding exercise that gives you a broken project to fix, or prompts you to explore where the code came from – this kind of inquiry is being used in the humanities to support the development of critical thinking skills, especially important since these tools might by default erode those very skills.

Then we have the wealth of problems that arise when people deploy applications with little to no understanding of their implementation. What happens over the long term, what happens if your project becomes a real thing people depend on, what happens when it breaks, what happens when it causes harm, how do we navigate the obfuscation of accountability? These are learning opportunities we’ll embrace if we want people to make more informed choices about how they use technology.

Software engineering is a very privileged profession, largely because it requires access to education. Vibe coding creates new paths into building with tech. The starting point may be different, but we might even manage to invite more people into the spaces where we shape the future of the web.

Learn how Fastly is making AI more sustainable.

Cover image is The March of Intellect by Robert Seymour.

Enhance an 11ty site at the edge

Sue Smith — Fri, 21 Mar 2025 14:01:26 +0000

In this post we're going to customize the UX in an Eleventy site with a Compute app running on the Fastly network at locations near your users around the world. We'll use the Eleventy Base Blog deployed to GitHub Pages, with some tweaks to its RSS feed to let us do some fun stuff at the edge. We'll write a JavaScript app that we'll compile into Web Assembly (Wasm) that can run securely on the Fastly network.

The website and feed

Eleventy (11ty) generates your website in the form of a bunch of HTML files and some CSS. This makes it a super fast, performant experience for the user – it also makes it perfect for playing with edge computing. You can do lots of cool things with 11ty plugins, like exposing an RSS feed of the posts in your site. We'll set our feed to return JSON so that we can mess with the data at the edge before sending it back to the user.

Set up your site

Our fork of the Eleventy Base Blog includes a change in eleventy.config.js to make the feed return JSON instead of the Atom format.

You can use the example site for your Compute app if you like, but later in this series we'll also try editing the site in conjunction with our edge functionality, so fork your own copy if you plan to follow along:

Fork the repo
Follow the steps in the README to edit and deploy to GitHub Pages – tl;dr:
- Edit the eleventy.config.js feedPlugin section to set metadata base to your own GitHub IO domain
- Change the references to my-site in package.json to your repo name
- Change .github/workflows/gh-pages.yml.sample to .github/workflows/gh-pages.yml
- Create a gh-pages branch
- In your repo Settings > Pages section, choose Deploy from a branch and select gh-pages
- Watch the Actions for your deploy status

Grab the URL for your new site, as you'll need it in your Compute setup.

Set up your Fastly account

Grab an API token from your account:

Go to Account > API tokens > Personal tokens
Click Create Token:
- Name: anything you like
- Type: Automation
- Role: Engineer
- Scope: Global (deselect the Read-only access box)
- Access: All services
- Expiration: Never expire
Copy the token value and save it on your computer

Set up your developer environment

We'll use the Fastly CLI to spin up a Compute service, so get it installed on your computer:

Create a new directory:

  mkdir 11ty-edge && cd 11ty-edge

Install the Fastly CLI – see the docs if you aren't using NPM:

  npm install -g @fastly/cli

Create a Fastly profile, entering the API token you copied from your account:

  fastly profile create

Start a Compute app

We're going to use Expressly, which lets us build our Compute app using a similar structure to Node.js server frameworks like Express. We'll listen for user requests, manipulating the request and response we send back to the user.

Initialize your Compute app using the Expressly starter kit:

  fastly compute init --from=https://github.com/fastly/compute-starter-kit-javascript-expressly

You can set the name, description, and author if you like, or accept the defaults.

💡 Include --accept-defaults with your Fastly commands if you don't want to respond to every prompt.

Run npm install when prompted.

Check your app is installed correctly by running it locally and opening it in your browser:

npm run start

The local site will just return OK.

Explore the app

Take a minute to explore the files in the Compute app.

The src/index.js file contains our Compute logic including the Expressly routing structures
The fastly.toml file contains our app setup

We'll be making changes to both of these files, and the Fastly tooling will change the TOML when we deploy our app.

💡 The bin and pkg directories include the compiled assets the CLI will use to deploy your app to Fastly.

Set up your origin

At the moment the app doesn't do much, it just returns a default response to the user. Let's get it to return the response from our 11ty website.

Open fastly.toml and add the following at the end of the file, changing the domain to your own GitHub IO subdomain if you're using your own version of the site deployed to GitHub Pages:

[setup]

  [setup.backends]

    [setup.backends.blog]
      address = "glitchdotcom.github.io"

In src/index.js, add a variable near the top of the script:

let backendResponse;

Change the router.use function to fetch the response from the origin site, making it async:

router.use(async (req, res) => {
  res.set("x-powered-by", "expressly");
  backendResponse = await fetch(req.url, {
    backend: "blog"
  });
});

We set the blog backend in the TOML, so Fastly will make the request to our origin website.

Delete the router.get('/'... and router.post("/submit" functions, replacing them with one to respond to all requests with the response from the origin site:

router.all("(.*)", async (req, res) => {
  res.send(backendResponse);
});

Your script should now look something like this:

/// <reference types="@fastly/js-compute" />

import { Router } from "@fastly/expressly";

const router = new Router();
let backendResponse;

router.use(async (req, res) => {
  res.set("x-powered-by", "expressly");
  backendResponse = await fetch(req.url, {
    backend: "blog"
  });
});

router.all("(.*)", async (req, res) => {
  res.send(backendResponse);
});

router.listen();

Deploy your app

In the terminal, exit from your local server with CTRL+C if necessary. Run the deploy command:

npm run deploy

Let the CLI create a new service, accepting the default options or changing any you like. The tooling will build and compile your app, upload the package to Fastly, and activate the service it's attached to. When it's ready, you'll see an edgecompute.app address in the terminal output – open it in your browser, adding the path for your GitHub repo name (my-site if you're using the example), like:

informally-one-shrimp.edgecompute.app/my-site/

Right now all the app will do is return the response from the origin website, but we're going to change the behavior for certain requests.

Build a synthetic feed page

Click the Feed link in the site header for your deployed app (at the edgecompute.app address – it just returns a JSON list of the posts in the site, which is what we get from the origin.

Let's turn this into a page. Back in your app, in the src/index.js file, add a new variable near the top of the script, changing the value to the name of your forked 11ty repo if you're using your own version:

let root = "/my-site/"; //change to your repo name

Add a new endpoint before the router.all("(.*)" section:

router.get(`${root}feed/feed.json`, async (req, res) => {
  let originData = await backendResponse.json();
  let posts = ``; // change to your repo name
  for (const pst of originData.items) {
    let date = new Date(pst.date_published);
    date = date.toDateString();
    let linkUrl = new URL(pst.url);
    posts += `<p><a href="${linkUrl.pathname}"><strong>${pst.title}</strong></a> – ${date}</p>`;
  }
  let page = `
  <!DOCTYPE html>
  <html>
    <head>
      <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1" />
      <title>${originData.title} – Feed 🗞️</title>
      <!-- 🚧 Change CSS location to suit your site 🚧 -->
      <link rel="stylesheet" href="${root}css/index.css"/>
    </head>
    <body>
      <header><a class="home-link" href="${root}">My Website</a></header>
      <h2>${originData.title} – Feed 🗞️</h2>
      <div>${posts}</div>
    </body>
  </html>`;

  res.withStatus(backendResponse.status).html(page);
});

The code parses the JSON feed response and builds it into HTML.

Deploy your app again:

npm run deploy

It may take a minute or so for your changes to update, but when your new service version is up, open the feed page again at the edgecompute.app address, like:

informally-one-shrimp.edgecompute.app/my-site/feed/feed.json

And we have a web page instead of the JSON data... 🎉

🧰 You can access a complete example of the app code in the 11ty-feed starter kit and Fiddle if you want to try running the code in the browser.

Next steps

⏳ Stay tuned for the next part of the series we'll add some edge data to the functionality – we can access information about the user, like their location, so we'll build that into our app processing to customize the site behavior.

In the meantime, check out how you can build edge data into your apps

Connecting your CDN to Fastly Object Storage

Antoine Brossault — Tue, 11 Mar 2025 20:38:30 +0000

Introduction

In this article, I'm going to explain how to get started with Fastly Object Storage and connect it to your Fastly CDN service. In just a few minutes you’ll be up and running with assets stored on Fastly Object Storage and served from your own URL!

First, what is Fastly Object Storage? It’s an S3 compatible object storage with no egress costs when you connect your Fastly Object Storage as an origin to your CDN service.

Fastly Object Storage is always a private bucket, which means you have to provide your CDN service with access and secret keys to connect to it. Therefore, you can’t simply use the object storage URL as the origin. You will need to add a bit of VCL to make it work, but it's not difficult.

Getting Started

To interact with Fastly Object Storage, you will need to create an access key in the Fastly control panel. This key consists of an access key ID and a secret key, which are used to authenticate requests to the S3-compatible API.

Log in to the Fastly web interface.
Navigate to Resources > Object Storage.
Click Create Key.
Enter a description and select the scope of access (read or read/write).
Be sure to note the access key and secret key, as the secret key will not be visible again.

Pro tip: For better security, you can restrict your API key to only access a specific bucket.

Now that you have created your keys, make sure you keep them somewhere safe. We are going to use them to create our first bucket.

Create your first bucket and upload files

Currently Fastly does not have a UI for creating a bucket and uploading your first file. However, you can accomplish it by using the AWS S3 CLI or any of the numerous packages and libraries available.

To make the process as easy as possible for you, I made a small GUI in Node.js that allows you to interact with the Fastly Object Storage seamlessly.

You can install the app with npm or Docker

Npm :

npx fastly-object-storage-easy-ui

Docker :

docker run -d -p 3009:3009 antoinebr/fastly-object-storage-easy-ui:latest

If the app is installed successfully, you can access it by visiting http://localhost:3009/.

Next, set your credentials in the UI and select the region where you want your files to be stored, along with the access key and secret key. Once that is done you can start creating your first bucket.

After creating your first bucket, click on “View files” to open the bucket, then proceed to your first upload.

How to access your files in the buckets ?

After uploading a file to the bucket, you will not be able to use the bucket URL to access the file directly, such as:

❌ https://eu-central.object.fastlystorage.app/<bucket-name>/<file-name>

You either need to use a proxy app which connects to the S3 bucket via API :

In this case, you can use a proxy app (as shown in the diagram above) and the speed will be limited to ~ 150Mbps and a max 100 req/s per bucket.

Use your bucket with your CDN service

The recommended way to use Object Storage is to connect a Fastly CDN service (via VCL) or Compute to your bucket. By doing so, no egress fees will apply, and there are no limitations with respect to speed or requests per second per bucket.

Integrating with Fastly CDN

Create a new service

You may already have an existing service, but for demonstration purposes, I’m going to create a new service:

The important part at this stage is to set the host. In my case, it is:

eu-central.object.fastlystorage.app

If you created your bucket in another region, set it to:

<your-region>.object.fastlystorage.app

Next, we need to inform our CDN service how to interact with our bucket. To do this, we need to add VCL snippets.

VCL Code for Object Storage Connection

Below is a VCL code snippet for connecting a Fastly CDN service to an Object Storage bucket. This code handles authentication and request signing for S3-compatible API requests.

Copy and paste the code in a vcl_miss (within subroutine).

/*

object storage connection

View Source 

Priority: 100

Type: miss

*/

declare local var.awsAccessKey STRING;

declare local var.awsSecretKey STRING;

declare local var.awsS3Bucket STRING;

declare local var.awsRegion STRING;

declare local var.awsS3Host STRING;

declare local var.canonicalHeaders STRING;

declare local var.signedHeaders STRING;

declare local var.canonicalRequest STRING;

declare local var.canonicalQuery STRING;

declare local var.stringToSign STRING;

declare local var.dateStamp STRING;

declare local var.signature STRING;

declare local var.scope STRING;

# Change these values to your own data

set var.awsAccessKey = "your_access_key"; # 👈 Update this

set var.awsSecretKey = "your_secret_key"; # 👈 Update this

set var.awsS3Bucket = "your_bucket_name"; # 👈 Update this

set var.awsRegion = "eu-central"; # 👈 Update this with your region of choice

set var.awsS3Host = var.awsRegion ".object.fastlystorage.app";

if (req.method == "GET" && !req.backend.is_shield) {

 set bereq.http.x-amz-content-sha256 = digest.hash_sha256("");

 set bereq.http.x-amz-date = strftime({"%Y%m%dT%H%M%SZ"}, now);

 set bereq.http.host = var.awsS3Host;

 set bereq.url = querystring.remove(bereq.url);

 set bereq.url = regsuball(urlencode(urldecode(bereq.url.path)), {"%2F"}, "/");

 set var.dateStamp = strftime({"%Y%m%d"}, now);

 set var.canonicalHeaders = ""

   "host:" bereq.http.host LF

   "x-amz-content-sha256:" bereq.http.x-amz-content-sha256 LF

   "x-amz-date:" bereq.http.x-amz-date LF

 ;

 set var.canonicalQuery = "";

 set var.signedHeaders = "host;x-amz-content-sha256;x-amz-date";

 set var.canonicalRequest = ""

   "GET" LF

   bereq.url.path LF

   var.canonicalQuery LF

   var.canonicalHeaders LF

   var.signedHeaders LF

   digest.hash_sha256("")

 ;

 set var.scope = var.dateStamp "/" var.awsRegion "/s3/aws4_request";

 set var.stringToSign = ""

   "AWS4-HMAC-SHA256" LF

   bereq.http.x-amz-date LF

   var.scope LF

   regsub(digest.hash_sha256(var.canonicalRequest),"^0x", "")

 ;

 set var.signature = digest.awsv4_hmac(

   var.awsSecretKey,

   var.dateStamp,

   var.awsRegion,

   "s3",

   var.stringToSign

 );

 set bereq.http.Authorization = "AWS4-HMAC-SHA256 "

   "Credential=" var.awsAccessKey "/" var.scope ", "

   "SignedHeaders=" var.signedHeaders ", "

   "Signature=" + regsub(var.signature,"^0x", "")

 ;

 unset bereq.http.Accept;

 unset bereq.http.Accept-Language;

 unset bereq.http.User-Agent;

 unset bereq.http.Fastly-Client-IP;

}

In the code, update the following lines:

set var.awsAccessKey = "your_access_key"; # 👈 Update this

set var.awsSecretKey = "your_secret_key"; # 👈 Update this

set var.awsS3Bucket = "your_bucket_name"; # 👈 Update this

set var.awsRegion = "eu-central"; # 👈 Update this with your region of choice

Save your snippet and activate your service.

Access your files :

After activating your service, you should be able to access your files from your CDN service.

https://<domain-name>/<bucket-name>/<file-name>

If you managed to follow the instructions up to this point, you should have a working connection between your CDN and Fastly Object Storage! Congrats 🎉

Extra tips :

To go beyond the basics of connecting your bucket, it's important to optimize delivery and caching performance. Here are a few tips for you:

Enable Segmented Caching for Large Files

Segmented Caching is essential for serving large files efficiently. It allows Fastly to split resources into smaller chunks, reducing load on the origin server and improving performance for Range requests.

Example :

Imagine a video streaming service hosting large videos (e.g., 4 GB movies) on Fastly. A user requests a portion of a video using a Range header to resume playback at 1 GB.

To enable Segmented Caching, add the following code to the vcl_recv subroutine:

# Enable Segmented Caching for large files

if (req.url.ext == "mp4") {

 set req.enable_segmented_caching = true;

 # Consider changing the segment size to reduce volume of requests going back to origin

 # The default is 1 MB. This would generate a 100 requests to origin for 100 MB file

 # or 1000 requests for a 1 GB file. The maximum size is 20 MB or 20971520 bytes

 # set segmented_caching.block_size = 20971520;

}

Enable Streaming Miss

The Streaming Miss feature ensures that responses are streamed back to the client immediately, reducing first-byte latency.

To enable Streaming Miss, add the following code to the vcl_fetch subroutine:

/*
Streaming Miss Feature
View Source 
Priority: 100
Type: fetch
*/

# Streaming Miss does not work with Gzip so you may want to wrap this in a condition
# based on file types that are likely to be Gzipped for example streaming manifests (m3u8 and mpd)
set beresp.do_stream = true;

Join the conversation in our forum

We would like to hear how you are using Fastly Object Storage. Be sure to visit our forum to let us know how we can support you better and to stay up-to-date on new capabilities released for Fastly Object Storage.

Announcing the Pub/Sub Compute app

Justin Karneges — Wed, 26 Feb 2025 19:44:25 +0000

We are excited to announce the Pub/Sub app for Fastly Compute, making it easy to push real-time updates to browsers and other devices. Messages are delivered via the Server-Sent Events or MQTT protocols. Check out the demo to see it in action, and read on to learn how to set up your own instance in minutes!

The Pub/Sub app is one of the first user-installable apps provided by Fastly that is production ready out of the box. It is not a template or starter kit that requires modification. Just install and go. Of course, since the code is open source, you are free to fork it and add your own functionality. We also welcome contributions.

You may know that Fastly also offers powerful real-time messaging capability via Fanout, however Fanout is designed for API operators with rigid requirements around messaging protocols, authentication, and storage. If you aren’t building or operating a push API and you simply want to send messages to browsers connected to your own website, then the Pub/Sub app is for you. Fun fact: the Pub/Sub app is built on top of Fanout!

The Pub/Sub app is highly scalable and there are no hard limits. It supports millions of concurrent connections and channels, and there is no limit to the number of subscriptions a single channel can have. Even though the app is user-installable, there is nothing to manage. Fastly runs the app entirely serverlessly, worldwide.

Getting started

To get started, clone the repo and use the fastly tool to deploy it:

git clone https://github.com/fastly/pubsub.git
cd pubsub
fastly compute publish

Assuming the fastly.toml file hasn't been modified, the above command will create a new Compute service and set up any related resources.

After that, enable Fanout on the service:

fastly products --enable=fanout

Add a backend called "self" to your service, for directing Fanout-managed requests back to the service itself. Replace {DOMAIN} with the domain selected during deployment:

fastly backend create \
  --name self \
  --address {DOMAIN} \
  --port 443 \
  --version latest --autoclone
fastly service-version activate --version latest

Determine the ID of the "secrets" Secret Store:

fastly resource-link list --version latest

Look for a block of output where the Resource Type is secret-store and the Name is whatever name you gave to the "secrets" Secret Store. The Resource ID is the store's ID.

Create a Fastly API token with the ability to publish Fanout messages. Do this by going to the Fastly management panel -> Accounts -> API tokens -> Personal tokens -> Create Token. Select Automation type, purge_select scope, limited to the service, and never expiring, and click Create Token. Then save the token in the above store:

fastly secret-store-entry create \
  -s {STORE_ID} \
  --name publish-token

The above command will prompt for the token value, which you can paste in.

Congrats, you have a pub/sub service! Next, we'll discuss how to use it.

Usage

Messages can be sent and received over HTTP or MQTT, and access must be authorized using tokens. In this section, we'll discuss how to send messages with HTTP.

First, you'll need a token signing key. Create one by sending a POST to the app's /admin/keys endpoint:

curl \
  -X POST \
  -H "Fastly-Key: $FASTLY_API_TOKEN" \
  https://{DOMAIN}/admin/keys

The app will respond with a key ID and value. Note them in a safe place. The value is used for signing JWTs. The ID must be included in the kid header field of the JWTs.

Once you have a signing key, you can create authorization tokens for subscribers and publishers as needed. Below is an example using Python and the PyJWT library to create a token allowing access to a topic named "test". Replace {KEY_ID} and {KEY_VALUE} with your key ID and value.

import jwt
import time

jwt.encode({
    "exp": int(time.time())+3600,
    "x-fastly-read": ["test"],
    "x-fastly-write": ["test"],
}, "{KEY_VALUE}", headers={"kid":"{KEY_ID}"})

Now that you have a token, you can subscribe a client. Here's an example using curl:

curl \
  -H "Authorization: Bearer $TOKEN" \
  "https://{DOMAIN}/events?topic=test"

The above command establishes a never-ending response body that the client can receive messages over.

And here's how to publish a message:

curl \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"text":"hello world"}'
  "https://{DOMAIN}/events?topic=test"

After running the above command, the earlier curl should output:

event: message
data: {"text":"hello world"}

For further details, including how to use the app with MQTT, see the README.

Questions/Comments?

Feel free to file issues on the GitHub repository for specific code related bugs or features, or chat with us on the Fastly Community Forum.

Private, cost-effective cloud storage that you will want to use!

Jaskirat Randhawa — Wed, 05 Feb 2025 21:18:44 +0000

If you are like me who wants private, affordable and easy to use storage, then Fastly Object Storage might be for you. It is an S3 compatible object storage with zero egress fees! Let’s take a look at how you can set it up and use S3 compatible tools to interact with your data. In this demo, I’ll walk you through connecting one of the popular tools SFTPGo, with Fastly Object Storage.

Prerequisites

This demo assumes that you have

A Fastly account with Fastly Object storage
A Fastly API Token set locally as $FASTLY_API_TOKEN
AWS CLI and Docker installed locally on your machine

Creating an Object Storage Key and a Bucket

Once you have the object storage available in your account, create an access key in the Fastly web interface. It consists of an access key ID and a secret key that is used to authenticate requests made to the Fastly Object Storage.

Log in to the Fastly web interface.
Navigate to Resources > Object Storage.
Click Create Key.
Enter a description and select the scope of access (Note: I am using read-write-admin for this demo.)
Note the access key and secret key, as the secret key will not be visible again.

Alternatively, if you have a Fastly API token, you can use curl to create an access key for object storage.

export FASTLY_API_TOKEN=xxxxx

# Create an access key using Fastly API token.
# It will create AWS_ACCESS_KEY and AWS_SECRET_KEY set of keys
curl \
-H "Fastly-Key: $FASTLY_API_TOKEN" \
-H "Content-Type: application/json" \
-X POST https://api.fastly.com/resources/object-storage/access-keys \
-d '{
  "description": "Demo access key",
  "permission": "read-write-admin",
  "buckets": ["sftpgo-bucket"]
}'

Configure AWS CLI and create a new Fastly profile nano ~/.aws/config. You can pick one of three available regions: us-west, us-east, or eu-central.

[default]
region = us-west

[profile fastly]
region = us-west
endpoint_url = https://us-west.object.fastlystorage.app

Here are some commands to configure the AWS CLI to work with Fastly Object Storage. Let’s create a bucket sftpgo-bucket that we will connect our SFTPGo client to in the next steps. Feel free to play around with using AWS CLI to interact with Fastly Object Storage. We will be able to see all the contents stored in the bucket using the SFTPGo client.

# Configure the AWS CLI
aws configure --profile fastly

# Create a bucket
aws s3 mb s3://sftpgo-bucket --profile fastly

# List buckets
aws s3 ls --profile fastly

# Upload a file
aws s3 cp ./sample.txt s3://sftpgo-bucket/ --profile fastly

# List contents of a bucket
aws s3 ls sftpgo-bucket --profile fastly

Using SFTPGo is as easy as 1-2-3

What is SFTPGo?

SFTPGo is one of my favorite file management solutions that supports S3 as a backend. One of the best things about it is that you can store and share files with your personal contacts or work colleagues with a convenient link sharing function. Advanced users can also find comfort in its abilities to create and manage users, folders, mounts and other resources. You can also go a step further to set up two-factor authentication.

We’ll keep it simple. All you have to do is:

Install SFTPGo
Add Fastly Object Storage as a backend
Done! You have a working setup.

There are multiple ways to install SFTPGo. I’m going to use docker-compose with minimal configuration. It’ll take less than 2 minutes to get up and running.

version: "3.8"
services:
  sftpgo:
    image: drakkan/sftpgo:latest
    container_name: some-sftpgo
    ports:
      - "8080:8080"
      - "2022:2022"
    volumes:
      - sftpgodata:/srv/sftpgo
      - sftpgohome:/var/lib/sftpgo
    restart: unless-stopped
volumes:
  sftpgodata:
  sftpgohome:

Create a docker-compose.yaml file and run docker-compose up -d to spin your service.

This will create a barebones SFTPGo server for you. You have plenty of customization options depending on your needs. Next, launch 127.0.0.1:8080/web/admin/login and run through the first time setup for the administrator. Provide the username and password that you’ll use to manage this instance. Note: Don’t worry if you lose these credentials or docker volume. Your data will still remain safe in Fastly Object Storage, because we’re using it as a backend.

The wonderful thing about this sort of a setup is that you can host your content without needing a degree in server management. It’s essentially your very own digital attic. You get to control everything. Now, you’re thinking, "Wait, I don’t want to mess around with code and stuff. I just want to store some content." No problem. Setting up Fastly Object Storage with SFTPGo is quite simple. You’re not building a spaceship here—just a safe space for your assets.

Here’s the breakdown:

Create a new user account

Once you log into the WebAdmin console, go to Users and click on Add to create a new user account. This is the simplest way to get started. You can, of course, do more than that like creating groups and virtual folders.

Configure the user account with following settings:

Storage: S3 (Compatible)
Bucket: Your bucket name
Region: us-west
Access Key: Generated earlier using Fastly API
Access Secret: Generated earlier using Fastly API
Endpoint: https://us-west.object.fastlystorage.app
Toggle on the option for Use path-style addressing

Done. Now test your setup

Go to 127.0.0.1:8080/web/client/login and log in with the credentials of the user that you just created. You should be able to see the contents of your storage bucket. Violá! You can now use the UI to upload, download and share your files.

To share files, click on options for a file or a folder. Then click on Share. It will prompt you with a few options to create a Share.

Once you’ve created a Share, you can go to Share in the left sidebar and get the options for viewing and managing your shares. Select the one you created and it’ll provide you a few links that you can pass along to others.

Easy to use storage that’s more private than your secret snack stash

So, there you have it: a private cloud storage that’s simple to set up, easy to share with your friends and colleagues (okay, family too). Once you set up the SFTPGo instance, you don’t need to manage any code. The best part? Using Fastly Object storage, you only pay for what you actually use.

Tell us how are you’re using Fastly Object Storage

I’m a product manager at Fastly and I would like to hear more about how you are using Fastly Object Storage for your personal or work life. What tools are you using? What tools would you like us to support? Join the conversation in our forum, and get started for free.

Go Beyond the Basics: Connecting Compute to Object Storage with the Official S3 Clients

Kay Sawada — Fri, 24 Jan 2025 21:42:24 +0000

Fastly Compute has consistently supported developers through its SDK with strong APIs for persistence needs, such as Config, Secret, and KV Store. Recently, we introduced Fastly Object Storage, an S3-compatible storage solution, which further streamlines the process of building systems on Fastly's Edge Network. With these advancements, the question arises: how best to connect Compute to Fastly Object Storage, particularly in terms of the most efficient connection methods? Fastly Object Storage is designed for S3-compatible API access, making it possible to connect from Compute via REST api call. But what's the most efficient way to do this?

In this article, I will guide you through using the official AWS SDKs to provide straightforward and intuitive access to Fastly Object Storage's API-compatible storage from Compute.

Use the official AWS SDK with Fastly Compute

Let's dive into some concrete code examples. In this first example, we're using the Compute Go SDK, which launched its official support in the summer of last year, along with AWS's official SDK(aws/aws-sdk-go-v2) to connect with Fastly Object Storage. What makes this approach particularly effective is its use of AWS's widely-adopted standard SDK, which enables intuitive handling of S3 objects. Developers familiar with this library can quickly access it with only a few lines of code, and even those new to the SDK will find it more efficient compared to directly handling the REST API. This efficiency is due to the well-developed documentation and the type hint and suggestions offered by the SDK. Additionally, aws/aws-sdk-go-v2 is particularly convenient because it supports interfaces for other AWS services beyond S3, such as RDS and Bedrock, which means this code can be adapted for use with other AWS services, too.

import (
   "context"
   "fmt"
   "net/http"
   "github.com/aws/aws-sdk-go-v2/aws"
   "github.com/aws/aws-sdk-go-v2/credentials"
   "github.com/aws/aws-sdk-go-v2/service/s3"
   "github.com/fastly/compute-sdk-go/fsthttp"
)

const (
   BUCKET_NAME = "YOUR_BUCKET_NAME"
   ACCESS_KEY = "YOUR_ACCESS_KEY"
   SECRET_KEY = "YOUR_SECRET_KEY"
)

func main() {
   fsthttp.ServeFunc(func(ctx context.Context, w fsthttp.ResponseWriter, r *fsthttp.Request) {
     // connect to s3
     customClient := &http.Client{
       Transport: fsthttp.NewTransport("origin_0"),
     }
     client := s3.New(s3.Options{
       Region:       "us-east",
       BaseEndpoint: aws.String("https://us-east.object.fastlystorage.app"),
       Credentials:  aws.NewCredentialsCache(credentials.NewStaticCredentialsProvider(ACCESS_KEY, SECRET_KEY, "")),
       UsePathStyle: true,
       HTTPClient:   customClient,
     })
     p := s3.NewListObjectsV2Paginator(client,&s3.ListObjectsV2Input{Bucket: aws.String(BUCKET_NAME)})

     // generate response html
     w.Header().Set("Content-Type", "text/html; charset=utf-8")
     fmt.Fprintf(w, "<html><body><ul>")
     for p.HasMorePages() {
       page, _ := p.NextPage(context.TODO())
       for _, obj := range page.Contents {
         fmt.Fprintf(w, "<li>Object:%s</li>", *obj.Key)
       }
     }
     fmt.Fprintf(w, "</ul></body></html>")
   })
}

The Secret Sauce

There's one crucial implementation detail worth highlighting in our example: we're injecting a custom client as the http.Client used by the AWS SDK, as shown below:

       customClient := &http.Client{
           Transport: fsthttp.NewTransport("origin_0"),
       }
       client := s3.New(s3.Options{
           ...
           HTTPClient:   customClient,
       })

When using external libraries within Fastly Compute, securing access to external system resources, such as file I/O or network operations, sometimes presents a challenge. For this scenario, the critical aspect is determining how to enable network communication. Thanks to Go's excellent abstraction in the net/http standard library, particularly the RoundTripper interface, it's relatively straightforward to ensure compatibility with external network resources. In fact, many libraries in Go are designed to allow the injection of a custom http.Client, which is advantageous in WebAssembly (WASI) environments, offering significant potential to leverage existing code assets. This adaptability is a notable strength of Go's Wasm target.

Note: To run the code demonstrated here, you'll need to configure a backend named “origin_0” with an endpoint URL in the format https://us-east.object.fastlystorage.app/ (No host override configuration is required).

What about JavaScript and Rust?

Of course we can connect with them, too! For JavaScript, in fact it’s much easier than the Go code above. All you need is to install the official AWS JS SDK by npm install @aws-sdk/client-s3 and add the following import statement at the top of the script;

import {
  paginateListBuckets,
  S3Client,
  S3ServiceException,
} from "@aws-sdk/client-s3";

Followed by some s3 operation like below;

   const client = new S3Client({
     region: 'us-east',
     endpoint: "https://us-east.object.fastlystorage.app",
     credentials: {
         accessKeyId: 'YOUR_ACCESS_KEY',
         secretAccessKey:'YOUR_SECRET_KEY',
     },
   });
   const buckets = [];
   for await (const page of paginateListBuckets({ client }, {})) {
     buckets.push(...page.Buckets);
   }
   console.log(buckets.map((bucket) => bucket.Name).join("\n"));

Lastly, in case of Rust, just like we did with Go SDK, we need a custom http client to inject to the AWS SDK for Rust to make its network layer functional with wasm32-wasi compilation target. A critical consideration for this work (the most challenging aspect) would be that the AWS SDK for Rust has a dependency on Tokio, which requires developers not only to implement asynchronous coding patterns but also to handle dependencies carefully.

For easier adoption of this SDK, I’d recommend you to visit this awesome repository(github.com/tidal-music/aws-fastly-http-client) created by Tidal Music, which enables you to have the AWS Rust SDK connect with backend servers through custom http client instantiated from FastlyHttpClient with ease. Simply git clone the project, and add your code and dependencies needed for your project - the final code should look something like below;

#[tokio::main(flavor = "current_thread")]
async fn main() {
   let custom_client = lib::FastlyHttpClient::from("origin_0");
   let config = aws_sdk_s3::Config::builder()
     .region(Some(Region::new("us-east")))
     .endpoint_url("https://us-east.object.fastlystorage.app/")
     .stalled_stream_protection(StalledStreamProtectionConfig::disabled())
     .identity_cache(IdentityCache::no_cache())
     .credentials_provider( aws_sdk_s3::config::Credentials::new(access_key, secret_key, None, None, ""))
     .http_client(custom_client)
     .behavior_version(BehaviorVersion::v2024_03_28())
     .force_path_style(true)
     .build();

   let client = aws_sdk_s3::Client::from_conf(config);
   let mut response = client
     .list_buckets()
     .send()
     .await
     .expect("unable to list buckets");

   for bucket in response.buckets() {
       let bucket_name = bucket.name().expect("no bucket name");
       println!("bucket_name:{}", bucket_name);
   }
   Response::from_status(StatusCode::OK).send_to_client();
}

Side note; There's a caveat with this Rust solution - you need to use fastly crate version 0.9.x alongside Rust compiler version 1.79.0. If you upgrade the Fastly crate version, you'll encounter compilation errors (e.g. type mismatch etc), as of writing this.

What's next?

The approach we've demonstrated using these AWS SDKs is just one way to connect Fastly Compute to Fastly Object Storage. The flexibility of S3 client options, combined with the injection pattern of custom http clients, opens up a world of possibilities for leveraging existing code assets and achieving intuitive development at the edge.

I encourage you to take advantage of these SDKs and libraries to enable smooth integration with Fastly Object Storage and other services, and set the stage for your next wave of innovation. Also, don’t forget to visit the forum and stay informed about the latest advancements of Fastly Object Storage. We welcome your contributions and look forward to seeing the innovative solutions you develop!

Forem: Fastly

Transform web pages at the edge

Start a new project

Enter project metadata

Write your logic

Grab geolocation info

Specify rewrite behavior

Test your app

Deploy your app

Keep going

Enabling developers in GitHub Codespaces

Wait, what is a codespace?

Containers

Previews and ports

Extensions

Custom buttons

Bash scripts

Deployment

Environment variables

File and feature visibility

Source control

Optimizing your repos for codespaces

Learn more

Develop an edge computing app in the browser

Fork the project

Get to know your new app

Develop in the browser

Deploy to the edge

Keep going

Publish your website without a host

Jump to:

Try a simple static site

Publish a project from your computer

Write and publish a blog from a codespace

Next steps

Go OTEL Traces without the Globals

Setup

HTTP Server

HTTP Client

Conclusion

Building an actually secure MCP Server with Fastly Compute

What is MCP?

Why Fastly’s platform makes MCP run better

How to build a remote MCP server with Fastly Compute

Adding support for legacy clients with SSE

Conclusion: What’s next?

We should still teach coding

Understanding incentives

The conditions for learning are in place

Encouraging inquiry and independent thought

Enhance an 11ty site at the edge

The website and feed

Set up your site

Set up your Fastly account

Set up your developer environment

Start a Compute app

Explore the app

Set up your origin

Deploy your app

Build a synthetic feed page

Next steps

Connecting your CDN to Fastly Object Storage

Create your first bucket and upload files

Use your bucket with your CDN service

Integrating with Fastly CDN

Create a new service

VCL Code for Object Storage Connection

Access your files :

Extra tips :

Enable Segmented Caching for Large Files

Enable Streaming Miss

Join the conversation in our forum

Announcing the Pub/Sub Compute app

Getting started

Usage

Questions/Comments?

Private, cost-effective cloud storage that you will want to use!

Prerequisites

Creating an Object Storage Key and a Bucket

Using SFTPGo is as easy as 1-2-3