How MyKinsta is laid out
Almost everything you will touch in week one lives under Sites, then your site name, then a tab: Domains, Backups, Caching, Tools, Analytics and User management. Company-wide settings such as company users and billing sit under Company settings instead. Kinsta's documentation uses these paths throughout, so it helps to learn them before you need them in a hurry.
A course site differs from a brochure site in three ways that change which defaults matter: students log in, so many requests cannot be served from cache; renewals, drip schedules and reminder emails depend on scheduled jobs and outgoing mail; and the database changes every time someone enrols or completes a lesson, so restoring an old backup loses real records. The table below maps each area to the check that matters for that reason.
| MyKinsta area | Path | What to confirm in week one |
|---|---|---|
| Domains | Sites > site > Domains | Domain verified, set as primary, both root and www added, Force HTTPS enabled under Tools |
| Caching | Sites > site > Caching | Edge caching enabled; login, account, register and checkout paths bypass the cache; you know how to clear server and CDN cache separately |
| Backups | Sites > site > Backups | Daily backups present; retention for your plan noted; one manual backup taken before launch changes |
| Staging | Sites > site, then its staging environment | A staging environment exists for plugin and LMS changes |
| Tools | Sites > site > Tools | Force HTTPS on, PHP version and Automatic PHP Updates setting chosen deliberately |
| User management | Company settings > Users, or Sites > site > User management | Each collaborator has the narrowest role; 2FA method known |
| Analytics | Sites > site > Analytics | Response codes, cache HIT/MISS/BYPASS and top requests reviewed after the first busy day |
Domains and HTTPS without downtime
Add the domain under Sites > site > Domains. The Add www. subdomain option is enabled by default, so both example.com and www.example.com are configured. Choosing Make primary domain does not change where the domain resolves; DNS still points wherever it pointed before until you change the records.
Kinsta offers two ways to point DNS. The quick setup shows A records (or CNAME records if your DNS is on Cloudflare) and Kinsta warns it may cause 1 to 3 minutes of downtime. The zero-downtime route verifies the domain first: add a TXT record named _cf-custom-hostname with the value MyKinsta shows, and a CNAME named _acme-challenge pointing to your domain followed by .validatedomain.cloud. Once verified, Kinsta issues a free SSL certificate with wildcard support through its Cloudflare integration, and only then do you change the A records. Kinsta says the quick route can cause 1 to 3 minutes of downtime (longer with a high DNS TTL) and the verified route can take up to 1.5 hours to go live, so for a site with paying students start the verified route well before your cutover window.
HTTPS is not forced automatically. Go to Tools and enable Force HTTPS so every HTTP request redirects to HTTPS.
Caching when students are logged in
Kinsta has three cache layers that behave differently. Server (full-page) caching stores generated HTML and expires every 24 hours by default; you can change the expiry under Caching > Server Caching, and that setting also applies to edge cache. Edge caching copies that page cache to Cloudflare's network, is included free on all plans, and is switched on under Caching > Edge Caching. The Kinsta CDN is separate again and serves static files such as images, CSS and JavaScript.
Edge caching documentation says logged-in areas such as the dashboard, forums and cart pages automatically bypass edge cache, and responses that set a cookie are not edge cached. The server caching page is less specific: it says dynamic pages such as checkout are not cached and that Kinsta Support can add bypass rules for pages such as /login, /account and /register. For a course site, open a support chat in week one and ask for bypass rules covering your login, registration, account, checkout and any profile or progress URLs your LMS uses, rather than assuming the defaults cover your plugin's paths.
Clearing server cache also clears edge cache and, if you have the Redis add-on, the Redis object cache, but not the CDN, which you clear separately under Caching > CDN. Manual clears are limited to one request every 10 seconds, whether from MyKinsta, the WordPress dashboard or WP-CLI.
- Log in as a test student in a private window and open a lesson; then log out and open the same URL. The logged-out view should never show the student's name or progress.
- Complete a lesson as the test student and reload: progress should update immediately, not after the 24-hour cache expiry.
- Check that the checkout page shows the current cart contents after adding and removing an item.
Backups: what exists and how long it lasts
Kinsta creates a full backup every day and lists it as a restore point in MyKinsta. A standard backup includes files, database, redirects, Nginx configuration, MyKinsta settings and domains, and backups do not count toward your disk allowance. Retention depends on the plan: 14 days on the entry plans (for example Single 35k and WP 2), 20 days on mid plans such as Single 500k and WP 20, and 30 days on the largest Single plans, WP 60 and above, and Agency plans.
| Backup type | How it is made | Kept for | Course-site note |
|---|---|---|---|
| Daily | Automatic, once a day | 14, 20 or 30 days by plan | Your baseline restore point |
| Manual | You create it; up to 5 at once | At least 14 days (varies by plan) | Take one before installing or updating the LMS, membership or payment plugin |
| System generated | Automatic before a restore, staging push, search and replace, plugin or theme update, or reset | 2 hours for manual plugin and theme update backups | A short safety net, not a long-term restore point |
| Hourly add-on | Every 6 hours ($20 per site a month) or every hour ($100 per site a month) | 24 hours | Shrinks the window of lost enrolments and orders after a restore |
| External add-on | Weekly or monthly to Amazon S3 or Google Cloud Storage | In your own bucket | $2 a month per site plus $1 per GB of bandwidth; cannot be restored directly in MyKinsta |
| Downloadable | One a week, ZIP of files and database | Download link valid 48 hours | Excludes redirects, custom Nginx rules, blocked IPs and PHP or MySQL configuration changes |
Staging before you change anything
Each WordPress install can have a free standard staging environment, and you can add up to 5 premium staging environments; Kinsta's proration example prices one month of premium staging at $20. Kinsta's comparison table lists standard staging at 1 CPU and 2 PHP threads with no CDN or edge caching, while premium matches the live environment's PHP threads, lists 12 CPUs and can enable CDN and edge caching. Standard staging may also go to sleep after 24 hours of inactivity. Full-page caching and OPcache are off on staging by default, so staging will feel slower than live and is not a fair speed test.
Staging is excluded from search indexing by default and sends an X-Robots-Tag header with noindex, nofollow, nosnippet and noarchive, which cannot be removed without a custom domain. That protects your live site, but it also means any canonical tag or sitemap generated on staging will reference the stg- or env- kinsta.cloud hostname; regenerate them after pushing to live.
Pushes can be files only, selected database tables, or both. Two details catch course sites: pushing only files does not create the database tables a newly installed plugin needs, and the Bot Protection setting is not transferred and must be set again on live. Because a database push overwrites live tables, do not push the database once students are enrolling unless you exclude the tables that hold enrolments, progress and orders.
Users and access
MyKinsta separates company roles from site roles. Kinsta applies two-factor authentication to all users, by email code or authenticator app, and Kinsta Support cannot add users on your behalf. Company Owners and Administrators can invite up to 10 addresses at once under Company settings > Users.
| Role | Scope | Can do | Give it to |
|---|---|---|---|
| Company Owner | Company | Everything, including closing the account and transferring ownership; only role that can cancel a plan | You, and only you |
| Company Administrator | Company | All company data and all sites, including migration requests | A business partner who must be able to act alone |
| Company Developer | Company | All sites, DNS and site-level users; can view but not change company-level users | An agency maintaining several sites |
| Company Billing | Company | Invoices and company details; no site access | Your bookkeeper |
| Site Administrator | One site | All environments of that site; cannot remove the site, handle migration requests or create and delete premium staging | A contractor responsible for one course site |
| Site Developer | One site | Staging environments only; cannot delete staging or push it to live | A freelancer building a new lesson template |
Email, scheduled jobs and updates
Kinsta does not host mailboxes; it recommends keeping email with a provider such as Google Workspace, Microsoft 365 or Zoho Mail. It does send transactional email from both live and staging sites through MailChannels, with a daily cap shared across all sites on the plan: 150 a day on the smallest plans, 1,000 on mid plans and 3,000 on the largest. Marketing mail must not be sent from Kinsta's servers, and Kinsta states that outbound transactional mail does not currently support DMARC alignment. A course with a few hundred students sending receipts, password resets and lesson reminders can pass 150 a day during a launch week, so most course sites should route WordPress mail through a third-party SMTP service from day one.
Server cron jobs are added to the site container's crontab over SSH with crontab -e; the minimum interval is 5 minutes, custom lines go at the bottom, and the lines at the top are managed by Kinsta and must not be moved. If your membership plugin relies on WP-Cron for renewals and drip release, decide in week one whether to keep WordPress's built-in cron or move it to a server cron entry.
Kinsta Automatic Updates is free for the first month and then $3 per environment per month. It updates plugins and themes once a day in a window you choose, compares before-and-after screenshots, and restores the pre-update backup (kept 3 days) if a significant visual change is found. WordPress's own auto-updates can run twice a day but do not test anything. Visual checks will not catch a broken checkout or a lesson that no longer marks complete, so keep a short manual test list as well. Under Tools > PHP settings, note that choosing an LTS PHP version disables Automatic PHP Updates.
Reading Analytics after the first busy day
MyKinsta Analytics is grouped into Plan usage, Top requests, Cache, CDN and edge, Performance, Response, Audience and Bot traffic, with data retained for 3 months. After your first day with real students, look at three things: the response code breakdown (a rise in 5xx means PHP or database trouble, a rise in 404 usually means a missed redirect), the cache section's HIT, MISS and BYPASS counts (a course site will show many BYPASS responses because logged-in requests skip cache, which is expected), and Top requests, where an unexpected path such as a heartbeat or search URL can reveal what is using PHP.
If pages feel slow, the APM tool is included at no extra charge and runs for 2, 4, 12 or 24 hours before switching itself off. It records PHP transactions, slow MySQL queries and slow external HTTP calls, keeps data for 14 days, and Kinsta warns it may slow the site while it runs, so use the shortest window that covers a busy period.
Week-one checklist
- Domain verified with the TXT and _acme-challenge records, then pointed; primary domain set; Force HTTPS enabled.
- Edge caching on; support has confirmed bypass rules for login, register, account, checkout and LMS progress paths.
- Plan's backup retention written down; one manual backup taken; a restore rehearsed on staging.
- Standard staging created; you know which database tables must never be pushed to live.
- Collaborators on Site Developer or Site Administrator rather than company roles where possible.
- Third-party SMTP configured for WordPress mail; daily send volume compared with the plan cap.
- Decision recorded on WP-Cron versus a server cron entry, and on Automatic Updates versus manual updates.
- Analytics response codes and cache statuses reviewed after the first day of real traffic.
Questions before you decide
How long does Kinsta keep daily backups?
Kinsta keeps daily backups for 14 days on entry plans, 20 days on mid-tier plans such as WP 20 and Single 500k, and 30 days on the largest Single plans, WP 60 and above, and Agency plans. Backups of a deleted site are kept for 14 days.
Does Kinsta cache pages for logged-in students?
Kinsta says edge caching automatically bypasses areas where a user is logged in, and server caching skips dynamic pages such as checkout. Support can add bypass rules for paths such as /login, /account and /register, so ask them to cover your LMS paths.
Can I host my course email inboxes on Kinsta?
No. Kinsta does not provide email hosting and recommends a separate provider such as Google Workspace. It sends transactional email with a per-plan daily cap of 150, 1,000 or 3,000 messages, and that mail does not support DMARC alignment.
Can a freelancer work on my site without touching live?
Yes. Kinsta's Site Developer role gives access to the standard and premium staging environments of the sites it is assigned and control only over those environments; it cannot remove a staging environment or push it to live.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Kinsta Docs: WordPress backups Accessed 30 Oct 2026
- Kinsta Docs: Adding a domain Accessed 30 Oct 2026
- Kinsta Docs: Server caching Accessed 30 Oct 2026
- Kinsta Docs: Edge caching Accessed 30 Oct 2026
- Kinsta Docs: Staging environment Accessed 30 Oct 2026
- Kinsta Docs: User management Accessed 30 Oct 2026
- Kinsta Docs: MyKinsta tools Accessed 30 Oct 2026
- Kinsta Docs: Email Accessed 30 Oct 2026
- Kinsta Docs: Cron jobs Accessed 30 Oct 2026
- Kinsta Docs: Automatic updates Accessed 30 Oct 2026
- Kinsta Docs: MyKinsta analytics Accessed 30 Oct 2026
- Kinsta Docs: APM tool Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.