Dear community,
I am currently working on a project using Edge Delivery Services with AEM as the content source. I have completed the migration of content from my development author environment to production using an AEM package. I have confirmed that both the site structure and assets are visible in the production author instance. The configurations between development and production environments are identical.
My main question is:
To switch the content source from the development author to the production author, is it sufficient to simply update the fstab file to point to the production author URL?
Since the paths.json should remain consistent after the content migration, I would like to confirm if this is the only required step.
I want to ensure that this approach will not introduce issues when new content is published from the production author, and that Edge Delivery Services will continue to function as expected without disruptions.
Could you please confirm if this is the correct and sufficient approach, or if there are additional considerations or best practices I should be aware of?
Thank you in advance for your guidance and support.
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @olsalas711,
In short - Yes, updating the fstab.yaml file to point to the production author URL is a key step, but it’s not the only thing to check. While paths.json can remain the same assuming the content structure is unchanged, there are a few more considerations to ensure everything works smoothly.
Double check these steps:
Update fstab.yaml:
Point the root and any mountpoint or external paths to the production author URL.
Ensure that authentication (if required) is configured correctly for the prod instance.
Verify authentication setup (if needed):
If your production author requires authentication for fetching content, ensure proper service credentials or tokens are configured for the EDS pipeline to access it.
Consider OAuth, basic auth, or service user credentials.
Ensure production author is publicly accessible (if required):
Edge Delivery Services must be able to reach the author instance. In Adobe’s recommended setups, this usually means using author preview pipelines or ensuring access via allowed IPs/CDN.
Check paths.json:
As you mentioned, if the content paths and structure are identical post-migration, you do not need to change paths.json.
Still, confirm that all critical paths (home page, error pages, etc.) resolve correctly in prod.
Review environment-specific code or configs:
Confirm that there's no hardcoded dev URLs or environment-specific code in your document rendering code (e.g., Excel, Word templates).
Ensure metadata like site domain, asset references, or page URLs reflect production URLs.
Validate content rendering via EDS:
Trigger a few builds from production author and preview them to confirm correct rendering.
Use hlx preview or the EDS preview URLs.
Hi @olsalas711,
In short - Yes, updating the fstab.yaml file to point to the production author URL is a key step, but it’s not the only thing to check. While paths.json can remain the same assuming the content structure is unchanged, there are a few more considerations to ensure everything works smoothly.
Double check these steps:
Update fstab.yaml:
Point the root and any mountpoint or external paths to the production author URL.
Ensure that authentication (if required) is configured correctly for the prod instance.
Verify authentication setup (if needed):
If your production author requires authentication for fetching content, ensure proper service credentials or tokens are configured for the EDS pipeline to access it.
Consider OAuth, basic auth, or service user credentials.
Ensure production author is publicly accessible (if required):
Edge Delivery Services must be able to reach the author instance. In Adobe’s recommended setups, this usually means using author preview pipelines or ensuring access via allowed IPs/CDN.
Check paths.json:
As you mentioned, if the content paths and structure are identical post-migration, you do not need to change paths.json.
Still, confirm that all critical paths (home page, error pages, etc.) resolve correctly in prod.
Review environment-specific code or configs:
Confirm that there's no hardcoded dev URLs or environment-specific code in your document rendering code (e.g., Excel, Word templates).
Ensure metadata like site domain, asset references, or page URLs reflect production URLs.
Validate content rendering via EDS:
Trigger a few builds from production author and preview them to confirm correct rendering.
Use hlx preview or the EDS preview URLs.
Hi @SantoshSai ,
Thanks for the detailed response — really helpful!
I’d like to dive a bit deeper into the authentication and access flow between Edge Delivery Services (EDS) and AEM Author, as I’m not fully sure if EDS sets up any built-in trust mechanism behind the scenes.
Even though I can open the production author URL directly from my browser (no basic auth or login prompt), I’m unsure whether EDS still requires explicit authentication or token-based access to fetch the content. Could you clarify:
Does EDS automatically handle access to AEM Author instances when they belong to the same Adobe Org, or should I configure credentials (e.g., OAuth, service user tokens) explicitly?
If authentication is required, where exactly should this configuration be placed? Is it part of the fstab.yaml mountpoint, the pipeline setup, or somewhere else?
What’s the recommended way to validate that EDS is successfully fetching from the production author once I switch the mountpoint? Should I expect specific errors if access fails, or are there tools/logs to verify this connection?
For context, here is our sanitized configuration:
fstab.yaml
mountpoints:
/:
url: "https://author-<env-id>.adobeaemcloud.com/bin/franklin.delivery/<org>/<project>/main"
type: "markup"
suffix: ".html"
folders:
/products/: "/products/default"
/categories/: "/categories/default"
/shop/: "/shop/default"
/new/: "/new/default"
/brands/: "/brands/default"
/promotions/: "/promotions/default"
/local/: "/local/default"
/p/: "/p/default"
paths.json
{
"mappings": [
"/content/project-store/:/",
"/content/project-store/headers:/.helix/headers.json",
"/content/project-store/configs:/configs.json",
"/content/project-store/configs-stage:/configs-stage.json",
"/content/project-store/configs-dev:/configs-dev.json",
"/content/project-store/placeholders:/placeholders.json"
],
"includes": ["/content/project-store/"]
}
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies