Maintainers:Fastly - Revision history

Starfish2228: update option names, fix syntax

2026-01-03T17:18:53Z

update option names, fix syntax

← Older revision		Revision as of 17:18, 3 January 2026
Line 35:		Line 35:
	[https://github.com/thoughtpolice Austin] currently has a Fastly service configured implementing some of the above. To use it, you can change your <code>substituters</code> setting. '''This uses the real upstream S3 bucket''', so you do not need to trust any new signatures. For NixOS users:		[https://github.com/thoughtpolice Austin] currently has a Fastly service configured implementing some of the above. To use it, you can change your <code>substituters</code> setting. '''This uses the real upstream S3 bucket''', so you do not need to trust any new signatures. For NixOS users:

	{{file\|~~/etc/nixos/configuration.nix~~\|~~nix~~\|<nowiki>		{{file\|\|\|<nowiki>
	~~{...}~~
	{		{
	nix.~~binaryCaches~~ = [ "https://aseipp-nix-cache.global.ssl.fastly.net" ]		nix.settings.substituters = [ "https://aseipp-nix-cache.global.ssl.fastly.net" ];
	}		}
	</nowiki>}}		</nowiki>\|name=/etc/nixos/configuration.nix\|lang=nix}}

	Nix users:		Nix users:

Phanirithvij: nixos fastly-configs are at nixos/infra asked Mic92

2024-09-15T08:53:40Z

nixos fastly-configs are at nixos/infra asked Mic92

← Older revision		Revision as of 08:53, 15 September 2024
Line 7:		Line 7:
	== Configuration details ==		== Configuration details ==

	The core configuration details for our services are located in [https://github.com/nixos/~~fastly-config fastly-config~~] ~~('''TODO: LINK FIXME''')~~, which you can quickly clone with git:		The core configuration details for our services are located in [https://github.com/nixos/infra infra], which you can quickly clone with git:

	{{Commands\|$ git clone https://github.com/nixos/~~fastly-configs~~}}		{{Commands\|$ git clone https://github.com/nixos/infra}}

	Check the <code>README.md</code> for details about the structure of the project, how to make and contribute changes, etc. It also describes the rough architecture of the integration(s).		Check the <code>README.md</code> for details about the structure of the project, how to make and contribute changes, etc. It also describes the rough architecture of the integration(s).

Phanirithvij: change the changelog url (taken from its home page)

2024-09-14T12:58:19Z

change the changelog url (taken from its home page)

← Older revision		Revision as of 12:58, 14 September 2024
Line 52:		Line 52:
	==== Changelog ====		==== Changelog ====

	We'll also have a changelog recording any major upgrades made to the service. You can view the current one here: https://aseipp~~-nix-cache~~.~~global~~.~~ssl.fastly.net~~/~~changelog~~		We'll also have a changelog recording any major upgrades made to the service. You can view the current one here: https://aseipp.notion.site/07c3be3df9f24d829471c6f8208a8570?v=41a80a849bb646d6a184bd1ce770edc4

	==== Beta + IPv6 + HTTP/2 ====		==== Beta + IPv6 + HTTP/2 ====

Phanirithvij: update url to wayback machine url

2024-09-14T10:23:16Z

update url to wayback machine url

← Older revision		Revision as of 10:23, 14 September 2024
Line 83:		Line 83:
	=== IPv6 shenanigans ===		=== IPv6 shenanigans ===

	See [https://github.com/NixOS/nixpkgs/issues/65015]. Some users report that turning off IPv6 helps download things from <code>cache.nixos.org</code>. See also on the Fastly support forums: [https://support.fastly.com/hc/en-us/community/posts/360040169531-I-often-can-t-access-Fastly-servers-using-HTTPS-IPv6-RST-packets-received I (often) can't access Fastly servers using HTTPS+IPv6: RST packets received]. It is unclear how widespread this issue might be. Using an IPv4 only DNS CNAME may mitigate this in the long run.		See [https://github.com/NixOS/nixpkgs/issues/65015]. Some users report that turning off IPv6 helps download things from <code>cache.nixos.org</code>. See also on the Fastly support forums: [https://web.archive.org/web/20221208122000/https://support.fastly.com/hc/en-us/community/posts/360040169531-I-often-can-t-access-Fastly-servers-using-HTTPS-IPv6-RST-packets-received I (often) can't access Fastly servers using HTTPS+IPv6: RST packets received]. It is unclear how widespread this issue might be. Using an IPv4 only DNS CNAME may mitigate this in the long run.

	== Future plans ==		== Future plans ==

imported>Thoughtpolice at 21:53, 5 August 2019

2019-08-05T21:53:06Z

← Older revision		Revision as of 21:53, 5 August 2019
Line 68:		Line 68:
	There are some known deficiencies with the beta, listed below:		There are some known deficiencies with the beta, listed below:

	* '''Overly-conservative URL blocking'''. The current implementation will only allow you to download <code>.narinfo</code>, <code>.ls</code>, and <code>.nar.xz</code> files -- this is to eliminate spurious/invalid requests to S3 for objects which could never possibly exist. If you see a 403 error returned from the server, then this is why. This should mean "recent" (few year old) evaluations should work fine -- ever since we've been using LZMA. This will be rectified in the future, but should only be noticeable to users on old channels.		* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.
			* '''Overly-conservative URL blocking'''. <s>The current implementation will only allow you to download <code>.narinfo</code>, <code>.ls</code>, and <code>.nar.xz</code> files -- this is to eliminate spurious/invalid requests to S3 for objects which could never possibly exist. If you see a 403 error returned from the server, then this is why. This should mean "recent" (few year old) evaluations should work fine -- ever since we've been using LZMA. This will be rectified in the future, but should only be noticeable to users on old channels.</s> <span style="color:#009000">'''FIXED'''</span>: This is now taken care of, and several other paths were fixed as well.
	** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.		** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.
	* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.
	* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. <s>We'll be applying to the LA program for TLS Origin support before deploying to production, and testing it carefully.</s> <span style="color:#009000">'''FIXED'''</span>: This is now taken care of -- the final, live deployment will use TLS Origins! The beta currently does not.		* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. <s>We'll be applying to the LA program for TLS Origin support before deploying to production, and testing it carefully.</s> <span style="color:#009000">'''FIXED'''</span>: This is now taken care of -- the final, live deployment will use TLS Origins! The beta currently does not.

imported>Thoughtpolice at 20:49, 5 August 2019

2019-08-05T20:49:08Z

← Older revision		Revision as of 20:49, 5 August 2019
Line 71:		Line 71:
	** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.		** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.
	* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.		* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.
	* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. We'll be applying to the LA program for TLS Origin support before deploying to production, and testing it carefully.		* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. <s>We'll be applying to the LA program for TLS Origin support before deploying to production, and testing it carefully.</s> <span style="color:#009000">'''FIXED'''</span>: This is now taken care of -- the final, live deployment will use TLS Origins! The beta currently does not.

	== Known issues ==		== Known issues ==

imported>Thoughtpolice at 13:36, 5 August 2019

2019-08-05T13:36:13Z

← Older revision		Revision as of 13:36, 5 August 2019
Line 71:		Line 71:
	** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.		** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.
	* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.		* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.
	* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. We'll be applying to the LA program for TLS Origin support, before deploying to production.		* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. We'll be applying to the LA program for TLS Origin support before deploying to production, and testing it carefully.

	== Known issues ==		== Known issues ==

imported>Thoughtpolice at 13:35, 5 August 2019

2019-08-05T13:35:08Z

← Older revision		Revision as of 13:35, 5 August 2019
Line 71:		Line 71:
	** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.		** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.
	* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.		* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.
			* '''Origin connections do not use TLS'''. When connecting to a Fastly POP, you use TLS. When Fastly POPs talk to each other, they also use TLS. When a POP talks to S3, '''the beta service does not use TLS''' -- it talks to S3 over HTTP. This is due to a limitation in a feature we use called '''[https://docs.fastly.com/guides/performance-tuning/streaming-miss Streaming Miss]''', which is vital in reducing <abbr title="Time To First Byte">TTFB</abbr> for large, uncached objects. (Without it, a POP must download an entire, possibly multi-hundred-MB NAR file before it can begin serving you. Streaming miss allows your download to start instantly.) Support for streaming miss with TLS origins is currently deployed in "Limited Availability" for Fastly customers. We'll be applying to the LA program for TLS Origin support, before deploying to production.

	== Known issues ==		== Known issues ==

imported>Thoughtpolice: Add changelog link

2019-08-05T12:57:38Z

Add changelog link

← Older revision		Revision as of 12:57, 5 August 2019
Line 49:		Line 49:

	You should be set. This uses the real upstream nixos.org binary cache as a backend, so it should basically be up to date with <code>cache.nixos.org</code>.		You should be set. This uses the real upstream nixos.org binary cache as a backend, so it should basically be up to date with <code>cache.nixos.org</code>.

			==== Changelog ====

			We'll also have a changelog recording any major upgrades made to the service. You can view the current one here: https://aseipp-nix-cache.global.ssl.fastly.net/changelog

	==== Beta + IPv6 + HTTP/2 ====		==== Beta + IPv6 + HTTP/2 ====

imported>Thoughtpolice: Add some other known issues

2019-08-05T04:55:06Z

Add some other known issues

← Older revision		Revision as of 04:55, 5 August 2019
Line 59:		Line 59:

	Note the difference in the DNS name: <code>global.ssl</code> vs <code>freetls</code>.		Note the difference in the DNS name: <code>global.ssl</code> vs <code>freetls</code>.

			==== Beta Issues ====

			There are some known deficiencies with the beta, listed below:

			* '''Overly-conservative URL blocking'''. The current implementation will only allow you to download <code>.narinfo</code>, <code>.ls</code>, and <code>.nar.xz</code> files -- this is to eliminate spurious/invalid requests to S3 for objects which could never possibly exist. If you see a 403 error returned from the server, then this is why. This should mean "recent" (few year old) evaluations should work fine -- ever since we've been using LZMA. This will be rectified in the future, but should only be noticeable to users on old channels.
			** We'll be sure to check the S3 metadata so that all filetypes in the cache can be downloaded properly, before final deployment.
			* '''Any user can purge cache objects with no authentication'''. Use <code>curl -v -X PURGE https://<SOME URL></code> in order to do so. This is useful for debugging user issues, but during final deployment, we'll want to turn this off.

	== Known issues ==		== Known issues ==