How Subdomain Publishing Works on Appzky.dev

When you publish an app on Appzky.dev, customers do not visit a confusing URL on our main site.

They visit your subdomain:

city-taxi.appzky.dev
legal-intake-smith.appzky.dev
downtown-clinic.appzky.dev

This guide explains how it works, what you need to configure, and what happens when a customer submits a request.

The publishing model

Each workspace app gets a globally unique publishSubdomain when you create it.

When you set the app status to active:

• The root of that subdomain serves your public flow (today: Taxi and Courier Booking)
• API routes handle form submissions securely
• Events land in your Operations feed
• Admins receive email notifications

Unpublished apps show a friendly "not live yet" message on the subdomain.

What your customer sees

For the live Taxi and Courier template, customers get:

• A mobile-friendly booking form
• Passenger or package / courier toggle
• Address fields (with Google Maps autocomplete when configured)
• Date and time picker
• Contact fields and optional notes
• A confirmation screen with a reference ID

No login required for end customers.

What you see as the operator

Inside your workspace:

• Operations — every booking, credit usage, and system event
• App detail — credit balance, publish controls, top-up packs
• Billing — plan status and credits across all apps
• Email — instant alert on each new booking

Credits and going live

Publishing requires at least 1 app credit in the app balance.

Each booking submission uses 1 credit. Your subscription refills credits per billing period; you can also buy top-up packs (25, 50, or 100) from the app dashboard.

If credits hit zero:

• New public submissions are paused
• You refill credits and publish again — no data loss

Canonical URLs

We redirect legacy paths for clarity:

appzky.dev/p/city-taxi  →  308  →  city-taxi.appzky.dev

Share the subdomain URL in marketing — it is the canonical customer-facing link.

DNS and SSL (for self-hosters and agencies)

Appzky.dev hosts subdomains on our infrastructure. As an operator you do not configure DNS per app — we handle *.appzky.dev routing.

If you are evaluating Appzky.dev on your own VPS:

• Wildcard DNS (*.appzky.dev) must point to the server
• A wildcard or edge SSL certificate must cover subdomains

Custom domains (e.g. bookings.yourclient.com) are planned for a later release.

Setting up Google Maps autocomplete (optional)

Add NEXT_PUBLIC_GOOGLE_MAPS_API_KEY to your environment with the Places API enabled.

Without a key, customers can still type full addresses manually — the form works either way.

Security and tenancy

• Public APIs only expose what is needed for the booking flow
• Submissions are scoped to the app resolved by subdomain
• Workspace data is isolated per organization
• Authenticated dashboard routes remain on appzky.dev/app

Checklist: first publish

• Create workspace and app from Taxi and Courier template
• Ensure app has credits (plan allocation or top-up)
• Click Publish booking page
• Open yourslug.appzky.dev in a private window and submit a test booking
• Confirm the event in Operations and your email inbox
• Share the subdomain link on your website and Google Business profile

What is next

More templates will publish the same way — one subdomain per app, one clear flow per niche.

Vote on blueprints in Support to influence release order.

Create your workspace →