1Footer documentation
Use 1Footer without Cloudflare
Choose native server, build or CMS delivery when your host does not permit Cloudflare proxying or you prefer your existing publishing workflow.
Last reviewed
Connect the system that publishes your website
Cloudflare is one delivery option. Released native adapters can publish the footer through your host, source repository or CMS without putting Cloudflare in front of the website. 1Footer coordinates supported checks and repairs in the cloud through the accounts connected to that website.
Choose the path for your current host and framework together. A supported framework on one host does not establish automatic repair on every other host. Keep the destination publishing account connected after a migration.
Native delivery options
Each path has its own framework, permission and recovery limits. A released adapter still needs a verified result on your actual public website.
| Website | Publishing path | Required setup |
|---|---|---|
| Vercel | Native server or response integration for supported Next.js, TanStack Start, Astro, SvelteKit, Nuxt and Remix / React Router projects. | Connect the current Vercel project and matching GitHub source when source preparation is needed. |
| Netlify | Source preparation, draft deployment and public delivery checks. | Connect Netlify publishing access and matching GitHub source access. |
| WordPress | Server-rendered footer through the 1Footer plugin. | Connect an installed current plugin, or supported hosting access for installation and recovery. |
| HubSpot | HTML/CSS snapshots through supported CMS templates. | Connect the portal serving the domain with the required CMS source permissions. |
| Shopify | Server-rendered Liquid snapshot through the theme publishing workflow. | Connect the actual store with permitted theme read/write access. Provider restrictions still apply. |
| Framer | Native export and connected Server API synchronization. | Install the footer and connect the matching publishing access. |
| Other server or static workflows | React server/build SDK or exported HTML and CSS. | Install in your own publishing workflow. A disconnected export needs republication after changes. |
When a native path is still in development
Wix end-to-end native installation, publishing and public verification remain unfinished. Native GitHub Pages orchestration is also in development; source repair and cleanup foundations do not provide a released managed connection.
Do not enable an incompatible proxy to bypass a missing native adapter. Shopify and Wix require native paths. For other platforms, use a released server/build package or export only where the website can actually publish it. A browser-only embed does not deliver the footer links in the initial HTML.
Publishing and migration checks still apply
Supported managed workflows schedule maintenance in the cloud. A manually exported snapshot stays at its last published version until your website publishes again.
- Publish your footer in 1Footer; an unpublished draft must stay private.
- Include both the current footer HTML and CSS in the website response.
- Preserve page rules and intentional pauses when changing delivery paths.
- Check the actual public domain after publishing, including navigation and excluded pages.
- Review destination repair and old-installation cleanup separately.