A New Foundation for Topcoder.com: Moving from Netlify and Contentful to AWS and Payload

The best infrastructure work is often invisible.

You visit Topcoder, find a challenge, read a case study, or explore the latest community news—and everything simply works. That was our goal as we completed two connected upgrades behind Topcoder.com.

We recently moved the website from Netlify into a dedicated Topcoder codebase and AWS delivery stack. At the same time, we migrated our content from Contentful to a self-managed implementation of the open-source Payload CMS.

This wasn’t a redesign for the sake of a redesign. It was about preserving the Topcoder experience while giving the platform a faster, more resilient, and more secure foundation.

Quick Summary

• Topcoder.com is now built as a static Next.js website and delivered through Topcoder’s AWS infrastructure.

• Website content is managed in Payload, an open-source CMS that we operate and customize ourselves.

• Public visitors do not connect directly to the CMS during normal browsing.

• Private storage, edge protection, tightly controlled access, and automated release checks strengthen our security.

• Existing content, URLs, relationships, redirects, and familiar page designs were preserved throughout the migration from Contentful.

• Website editors now have improved previews, version history, recovery tools, and purpose-built workflows for blogs, case studies, Thrive articles, and other content.

The Old Way: Effective, but Spread Across Multiple Platforms

Netlify and Contentful served Topcoder well. Netlify built and hosted the website, while Contentful stored the pages, articles, media, and structured content behind it.

Over time, however, the website’s critical path became spread across several external platforms and integration layers. Hosting, content, media, search, previews, and dynamic features each had their own configuration and unique integration quirks.

That made changes harder to coordinate and gave us less control over how the complete system was secured, tested, deployed, and recovered.

Additionally, the cost was prohibitive for each. Netlify wasn't overly expensive, but Contentful was far too expensive for what we were doing with it and our contract was up for renewals in September 2026.

The goal of this migration was to cut costs considerably by self-hosting and to bring the website hosting and content management into our AWS stack to better align with the platform.

The New Website: Static by Default, Dynamic Where Needed

The new Topcoder website lives in a dedicated Next.js codebase managed by Topcoder.

During each release, the build retrieves one consistent, published snapshot from Payload. It validates that snapshot and generates the website’s pages, blog listings, search index, sitemap, route manifest, and redirects together.

Those static files are stored in a private Amazon S3 origin and delivered through Amazon CloudFront, which serves content through a global network of edge locations.

For users, that means less work has to happen when a page is requested. Most of the website is already rendered and can be delivered from an edge location close to the visitor.

Static does not mean inflexible. Features that genuinely need live data—such as forms, challenge information, and leaderboards, continue to use controlled Topcoder APIs. The difference is that these dynamic routes are now clearly separated from the public content layer.

Moving from Contentful to Payload

Our second major change was replacing Contentful with Payload.

Payload is an open-source, Next.js-native CMS. Its public repository is MIT-licensed, allowing us to inspect, extend, and operate the software within our own infrastructure.

That gives Topcoder greater control over:

• How content is modeled

• Where content and media are stored

• How administrators authenticate - now through SSO instead of separate accounts

• Which applications may access the CMS

• How content changes are reviewed and released

• When dependencies and security updates are applied

• Which editorial features we build next

The new CMS uses PostgreSQL for structured content, while media is stored in private S3 storage and distributed through a Topcoder-controlled CloudFront origin.

We also built a compatibility layer that preserves the content structures expected by existing Topcoder applications. That allowed us to move away from Contentful without requiring every connected application to be rewritten at once.

Original content identifiers, relationships, publication states, routes, and asset references were retained wherever needed. This made the transition gradual and testable instead of a risky “big bang” replacement.

A Better Experience for Editors—and Better Content for Users

Moving to Payload also allowed us to build editorial workflows around the way Topcoder actually creates content.

Editors now have access to:

• Dedicated forms for Blog posts, Thrive articles, and Case Studies

• Drafts and automatic saving

• Live Preview using the real Topcoder website

• Mobile, tablet, and desktop preview controls

• Version history and rollback

• Recoverable Trash for accidentally deleted content

• Integrated media uploads and alternative-text fields

• EO metadata and redirect management

• Clearer relationships between pages, authors, categories, images, and related content

These may sound like behind-the-scenes improvements, but they have a direct effect on what users see.

Editors can catch layout issues before publication, recover from mistakes, manage redirects when URLs change, and produce more consistent, accessible content. The result is a safer publishing process and a better experience for everyone reading Topcoder.com.

Security Is Built Into the New Architecture

Open source by itself is not a security control. Security depends on how software is configured, operated, monitored, and updated.

The new platform adds several layers of protection.

The CMS Is Not in the Public Browsing Path

Normal visits to Topcoder.com do not make requests to Payload or expose a CMS credential. Published content is retrieved during the protected build process and becomes part of the static release.

If the CMS is temporarily unavailable, already-published website pages can continue to be served.

Private Origins and Edge Protection

Website files and media are stored in private S3 buckets. CloudFront is the public delivery layer, preventing visitors from accessing the underlying storage directly.

Traffic passes through security headers and AWS WAF protections before it reaches the relevant application or API.

Controlled Administrative Access

Payload uses Topcoder’s shared sign-in flow, and CMS access is restricted to approved administrator roles. Browser origins, preview sessions, uploads, and content-management operations are checked against explicit access rules.

Application secrets remain in protected runtime configuration rather than public JavaScript or website artifacts.

Releases Fail Closed

Before a website release can be deployed, automated checks validate the content schema, relationships, routes, asset origins, redirects, and expected content volume.

The build also scans for credentials and unapproved references to retired hosting or content providers. If content is incomplete, inconsistent, or points to an unexpected external origin, the release stops instead of publishing a partially broken website.

Recovery Was Part of the Design

CMS content has version history, drafts, and recoverable deletion. Website releases and assets are versioned, while database snapshots and rollback procedures protect larger operational changes.

The objective is not only to prevent problems, but also to make recovery predictable if one occurs.

Why This Matters for You

You shouldn’t need to understand the architecture to benefit from it.
The new foundation gives Topcoder users:

• Faster, more consistent delivery: Static pages require less runtime processing and can be served through CloudFront’s global edge network.

• Greater resilience: Published pages are not dependent on a live CMS request every time someone visits them.

• Stronger protection: Private storage, edge filtering, security headers, server-side secrets, and release validation reduce the public attack surface.

• Stable routes and content: Existing links, redirects, page structures, and familiar designs were preserved.

• Better content quality: Live Preview, version history, SEO controls, and safer publishing workflows help editors catch issues before they reach users.

• Faster platform improvements: Owning the website and CMS code gives us more freedom to fix issues, add features, and adapt the system to Topcoder’s needs.

Looking Ahead

Netlify and Contentful helped power an important chapter of Topcoder.com. This transition is about preparing for the next one.

We now have a website and content platform that we can inspect, extend, secure, and improve as one Topcoder-managed system. It reduces external dependencies while giving our engineering and content teams more control over the experience delivered to members and customers.

The most visible part of Topcoder is still the work of our community: the challenges, stories, solutions, and opportunities shared across the platform.

Underneath it, however, is a new foundation—one designed to keep that experience fast, dependable, and secure for the years ahead.