yourproject.hiveku.com as soon as you deploy. You can choose between two hosting types depending on your project’s needs.
Hosting types
- Serverless (default)
- Container
The default option for most projects. Your site is served from a global CDN with automatic scaling. Best for static sites, JAMstack apps, and lightweight server-side rendering.
- Zero cold starts for static assets
- Automatic scaling to handle traffic spikes
- No infrastructure to manage
Hosting dashboard
The hosting dashboard shows:- Status — whether your site is live, building, or stopped
- Log viewer — real-time server logs and build output
- Integrations — hosting add-ons (see below)
- Firewall — what the edge firewall challenged or blocked for this site in the last 7 days, and the clients you have allowed through (see below)
Cron jobs
Schedule recurring tasks that run on your hosting environment.1
Enable cron jobs
Go to Hosting > Cron Jobs and toggle the feature on.
2
Choose environment
Select whether the cron job runs in your serverless or container environment.
3
Add a job
Enter a cron expression (e.g.,
0 */6 * * * for every 6 hours), the command to run, and an optional description.4
Run now (optional)
Click Run Now to test the job immediately without waiting for the schedule.
Redirects
Manage URL redirects from the Hosting > Redirects tab.
You can also:
- Import/export CSV to manage redirects in bulk
- Set a custom 404 handling page
- Use up to 150 redirect rules per project
Firewall
Every Hiveku-hosted site sits behind Hiveku’s edge firewall. It refuses requests from known bulk-scraper networks and stops automated clients it cannot identify. Real visitors, search engines, AI assistants, link previews and common uptime monitors pass. The Hosting > Firewall section shows what was challenged, blocked or rate limited for your site over the last 7 days and lets you allow a specific client — your uptime monitor, your agency’s audit tool — without turning protection off. Its client table has an outcome filter, a search and Show more to page through the rest of the list, and each row opens the client’s detail. An automated client the firewall cannot identify gets a202 challenge (empty body, x-amzn-waf-action: challenge) or a 403 with x-hiveku-firewall: blocked; a request from a known bulk-scraper network gets a 403 with x-hiveku-firewall: blocked-network; a 403 without that header comes from the site itself. A firewall answer is not an empty or broken page. A monitor or audit tool you run should send its own product name and version in its user agent (such as MyMonitor/2.1) and be allowed under Hosting > Firewall. An allowance lets a client past the browser check and past the refusal of automated clients the firewall cannot identify; it never lifts the per-address rate limit, the high-volume challenge or the block on known bulk-scraper networks. See Allow a monitor through the firewall.
Real Googlebot and bingbot are verified by the address they come from and need no allowance; a test that fakes their name from an office or a laptop is refused on purpose. See Is Google or Bing blocked? for how to check what they see.