Set it up with
your usual AI.

Give the prompt below to an AI that can inspect your project. You do not need to know where it is hosted.

This page does not send anything to an AI or change your settings. You can also copy the text manually. AI usage costs depend on your own plan.

1. Identify your hosting

   The AI checks the actual deployment and reads that product’s current official instructions.

2. Choose after checking costs

   Review compatibility, the required changes and any additional charges before purchasing or changing settings.

3. Connect and test your site

   Sign in yourself and configure the address and target. Then test login, forms and other app features at the new address.

Find an address → · Set up an address you already own

Connect GitHub Pages

For static sites. Live DNS, ownership verification and HTTPS tested.

Hosting uses such as a commercial SaaS or online store are restricted.

1. Publish your site

   Use your repository’s Settings → Pages and check its default URL. GitHub Free requires a public repository.

2. Verify the address

   Add your rented hostname in your account or organization’s Settings → Pages. Save the exact TXT name and value in banchi’s individual DNS settings, then press Verify in GitHub.

3. Connect both sides

   Add the hostname to the repository’s Pages → Custom domain. In banchi, choose GitHub Pages and enter owner.github.io as the target, with the GitHub owner name and verification TXT value. Do not add a repository path.

4. Enable HTTPS

   Wait for the certificate, then enable Enforce HTTPS. Keep the verification TXT and test your site at its new address.

Check login, forms and other app settings →

Connect Cloudflare Pages

Connection and HTTPS across separate Cloudflare accounts tested.

1. Publish on Pages

   Check that your site and APIs work at the project’s pages.dev URL.

2. Add your address to Pages

   Open Custom domains → Set up a custom domain and add your rented hostname. Do not add the parent domain as a new Cloudflare site. If the account also controls the parent zone, inspect automatic DNS changes before confirming and stop if they would overwrite banchi-managed DNS.

3. Save the target in banchi

   Choose Cloudflare Pages and paste the CNAME target shown by Pages into Target value. Add the address on Pages first, before saving DNS.

4. Check HTTPS

   Wait for Pages to activate the domain, then press Check status in banchi. Test forms and APIs at the new address too.

Check login, forms and other app settings →

Connect Vercel

Connection, certificate issuance and cleanup tested on September 7, 2026.

The free Hobby plan is for personal, non-commercial use. Check your plan before commercial use.

1. Add your address to Vercel

   Check the project’s default URL, then add the rented hostname in Settings → Domains.

2. Copy the CNAME target

   Copy the complete project-specific target shown by Vercel, including any trailing numbers.

3. Save it in banchi

   Choose Vercel and paste the target into Target value. Enter a verification TXT value only if Vercel requests it.

4. Wait for HTTPS

   Once Vercel issues the certificate, press Check status in banchi. Test the site, sign-in and APIs at the new address.

Check login, forms and other app settings →

Connect Netlify

Connection, certificate issuance and cleanup tested on September 7, 2026.

1. Add your address to Netlify

   Check the site’s default URL, then add the rented hostname in Domain management.

2. Use external DNS

   Choose to keep your existing DNS. Do not transfer banchi.app to Netlify or change its nameservers.

3. Save the CNAME in banchi

   Choose Netlify and paste the target it provides, such as site.netlify.app, into Target value.

4. Check HTTPS

   Confirm DNS verification and certificate issuance in Netlify’s HTTPS settings. Then test the site, forms and APIs at the new address.

Check login, forms and other app settings →

Your own server (VPS) setup

Verified end to end on 2026-09-07 with a GCE e2-micro instance running Caddy (automatic certificate issuance and removal confirmed)

Required: a reachable public IP, a server configured for your hostname, and HTTPS. The usual setup below needs inbound TCP ports 80 and 443. Home hosting can be possible if these conditions are met; check CGNAT, router and firewall rules, and your connection terms. A global IPv6 address alone does not establish reachability.

1. Set your rented hostname in the web server's allowed hosts or virtual host.
2. In banchi, choose Other (CNAME / IPv4 / IPv6) and paste one IPv4 or IPv6 address from your server into "Target value".
   Note: to use both, add an A and an AAAA record side by side in individual DNS settings.
3. Configure an HTTPS frontend such as Caddy. Caddy normally uses HTTP-01 on port 80 or TLS-ALPN-01 on port 443. Renewal needs a running service, writable persistent certificate storage, and continued DNS and network reachability. With nginx and Certbot, also verify the renewal timer and loading of renewed certificates.
4. Manual DNS-01 can be an option when HTTP validation is unavailable; it is not limited to wildcard certificates. banchi does not provide DNS-01 renewal automation or wildcard DNS records.

Caddy and nginx/Certbot configuration and verification commands (Markdown)

Let's Encrypt challenge types · Caddy automatic HTTPS · certbot

Cloudflare Workers

Add one Pages entry point to use your existing Worker.

Keep your app, databases and scheduled jobs. banchi provides DNS; traffic is handled in your own Cloudflare account.

If only the original URL has Access or similar protection, check authentication before publishing.

1. Enter your rented address and deployed Worker name in the two entry files below.
2. Deploy them as a new Pages project in the same account as the Worker.
3. Add your address under Pages Custom domains. In banchi, choose Cloudflare Pages and save the supplied production pages.dev target.
4. Once the certificate is active, check sign-in, forms and assets at your rented address.

export default {
  fetch(request, env) {
    if (new URL(request.url).origin !== env.PUBLIC_ORIGIN) {
      return new Response('Not found', { status: 404 });
    }
    if (!env.APP) {
      return new Response('Service unavailable', {
        status: 503, headers: { 'Cache-Control': 'no-store' },
      });
    }
    return env.APP.fetch(request);
  },
};

{
  "name": "my-worker-entry",
  "pages_build_output_dir": "./dist",
  "compatibility_date": "2026-09-09",
  "vars": {},
  "services": [],
  "env": {
    "production": {
      "vars": { "PUBLIC_ORIGIN": "https://your-name.banchi.app" },
      "services": [{ "binding": "APP", "service": "existing-worker" }]
    },
    "preview": {
      "vars": { "PUBLIC_ORIGIN": "" },
      "services": []
    }
  }
}

cd pages-entry
wrangler pages project create my-worker-entry --production-branch main
wrangler pages deploy ./dist --project-name my-worker-entry --branch main

Detailed technical manual (Markdown, section 8) →

Redirect to an existing URL

Use this to send visitors to a page you already publish. You do not enter DNS records or register your rented hostname with the destination. It uses a 302 (temporary) redirect, so the browser's displayed URL changes to the destination.

1. Sign in to the account that acquired the address, then open Address settings from Your addresses. The usage choices open after acquiring an address. For an address already configured, press Change how it is used.
2. Select Redirect to another URL, enter a working, complete URL in Redirect URL (https:// recommended), then save with Use this. A page path is allowed. The rented hostname itself cannot be the destination.
3. Open your rented address and confirm that both the browser's displayed URL and the page match your intended destination. Every request goes to the one URL you saved; paths and queries added to the rented address are not carried over.

Switching from a DNS connection schedules all records for that address for removal, including child names, ownership verification TXT and CAA records. Deletion in progress or cached DNS may still send visitors to the old host after saving. Remove the old host's custom domain registration only after confirming the redirect works, the old DNS records are removed, and their caches have expired. Contact us if the switch does not complete.

Four steps to connect

1. Publish your site on your hosting

   Check that the site opens at your hosting's standard URL. Check whether your plan supports custom domains. Also check which DNS record types your host requires.

2. Register the address with your host

   In banchi, open Your addresses → Address settings and copy the hostname. Paste it into Custom domain on your host.
   Required: Do not include https:// or a trailing path — enter the complete hostname.

3. Save the target in banchi

   Choose Connect to my own hosting. For an address already configured, press Change how it is used first. Pick your hosting's preset, paste the value into Target value, and save with Connect with this value.
   Required: Paste only one CNAME target, or one IPv4 or IPv6 address — no paths or port numbers.

   Note: for multiple IP addresses, additional names, or web TXT/CAA records, use individual DNS settings.

4. Wait, then press Check status

   Wait for your host to issue its certificate, then press Check status in banchi. Once it shows Connected, open your new address.
   Timing: depends on your host and DNS caches. / What you might see: look the message up in how to read the diagnosis. / Next: continue to app settings and checks.

banchi's diagnosis looks at two DNS resolvers and an HTTPS response of 200–399 at the root. It does not confirm a successful sign-in, a completed post, or a successful payment.

Configure individual DNS records

In address settings, open Edit DNS records and enter the type, name and value your host requests. These examples use your-name.banchi.app as the rented address.

How to write the name

The rented address itself (root)

The root is the rented address itself. Enter @ or your-name.banchi.app.

Names below your address

Enter the complete hostname, such as www.your-name.banchi.app. The same applies to api.dev.your-name.banchi.app and _verify.your-name.banchi.app.
Required: A relative name such as www alone cannot be used. Other customers' addresses and wildcards such as *.your-name.banchi.app are not accepted either.

Record types

A and AAAA

Enter your host's IPv4 or IPv6 address. Multiple IP addresses at the same name are supported. Private-network-only and certain reserved addresses are not accepted.

CNAME

A CNAME is where an alias points. Enter the complete destination hostname from your host.
Required: No other record can share the same name. A root CNAME and a root TXT cannot coexist. Use a different verification name only when your host explicitly specifies it. If required names conflict, keep the specified names and contact support.

TXT

Used for things like web service ownership verification. You can also manually enter a certificate challenge TXT (DNS-01, explained below). This does not include renewal automation. Email records such as SPF, DKIM and DMARC are out of scope.

CAA

The setting that names which certificate issuer (certificate authority) your host wants, for example 0 issue "letsencrypt.org".
Required: Match it to the authority you actually use. An incorrect value can block certificate issuance or renewal.

Record limits and what you can save first

Required: The standard limit is five records per address. Verification TXT, CAA and banchi's own notice record all count toward it. While no root A, AAAA or CNAME is set, one notice record sits at the root, leaving four for you to use.

The notice record is the one banchi adds automatically while no root target is set. Once you set a root target it is replaced automatically, so you never edit it by hand.

You can save a verification TXT record first and set the hosting target later. You can also use only a child hostname without publishing at the root. Note that banchi's HTTPS check covers the root only. For every name you add, check its registration, certificate and app behavior yourself.

How to read the diagnosis

App settings and tests before launch

Some settings need a second look whenever your URL changes. Check only the ones that apply to you. This work is also needed when changing a regular custom domain.

Pages, images and APIs

Open and reload the home page and a deep link at the new address. Check public URLs, asset paths and API endpoints for old hostnames or HTTP links.

Sign-in

Update allowed URLs and OAuth callback URLs with your authentication provider. Test sign-in, reload and sign-out. Some providers require the full callback path to match.

Posting, forms and APIs on another host

Register only the required new URLs in your connected app's allowed Origin (the sites it accepts requests from), CORS and CSRF settings — CSRF protection is what blocks forged submissions from other sites. Submit a real test and check the saved result, not just the on-screen message.
Required: Do not disable CORS checks across the board.

Human verification, such as Turnstile

The widget's owner must add your rented hostname to its allow list. For Turnstile, do not include https:// or a path. After adding it, check the form at the new address.
Required: Avoid allowing the whole banchi.app domain, since that includes other customers too.

Cookies and sessions

Omit the cookie's Domain attribute so it is scoped to your own host. Do not set it to the parent banchi.app. A cookie whose name starts with __Host- is marked for that one host only; give it Secure; Path=/ and no Domain attribute.
Required: Do not rely on SameSite alone — verify the request's origin too, since browsers can treat everything under banchi.app as "the same site".

Payments inside your app

If your hosted app takes payments, update success, cancel and portal return URLs. If moving webhooks, update the endpoint and verify signatures. Test success, cancellation and duplicate notifications in a test environment. These settings are separate from paying banchi for the address. Detailed checks (Markdown)

WebSockets, video and files

If used, test connection, disconnection, reconnection, playback and any required partial downloads at the new address. A successful DNS check does not verify these features.

HTTPS and browsers

Check that no certificate warning appears, that it displays correctly on a phone, and reload after important actions.
Required: Do not treat the launch as complete while ignoring a certificate warning.

Turnstile hostnames · CORS · Cookie scope

When something does not work

Still stuck? Use the bug report form. Include your hostname, hosting service, time, steps and diagnostic code. No GitHub account is required and reports are handled privately. Do not include passwords, private keys, cookies or sign-in links.

Supported DNS and differences from owning a domain

What you can do

A, AAAA, CNAME, web verification TXT and CAA records at your rented hostname and multiple levels below it, up to five records.

What you cannot do

Email settings such as MX, SPF, DKIM and DMARC, NS delegation, wildcards, and settings on other customers' addresses. This is not a restriction of subdomains as a mechanism — it is banchi's current supported scope.

Ownership and continued use

You rent the subdomain for your contract period. It does not include ownership of the parent domain. You cannot transfer the same name to another registrar.

Certificate and browser boundaries

Certificate issuance limits, and the range a browser treats as "the same site", may be shared under the parent domain. The parent domain's DNS, registration and reputation can have shared effects too. Scope cookies and authentication permissions to your own hostname.

Traffic and protection

Site traffic charges and attack handling depend on your hosting contract and configuration. banchi's fee does not include a server, unlimited destination traffic or destination attack protection.

Changing hosts, stopping renewal and leaving

When changing hosts

Register the hostname on the new host first, then change banchi's target and verify it. Some traffic can still reach the old host while DNS changes propagate. Remove the old deployment only after confirming the switch.

Price and automatic renewal

The price is ¥500 per address per year, including tax. One email address can own multiple addresses, each with its own separate contract and renewal date. Use Review cancellation to check the contract for that address and confirm the stop in Stripe. The address stays usable through its paid period. Sales are limited to residents of Japan.

Ending your use

Required: In banchi, choose Stop connecting and go back to park first. Park is the state that shows a notice page saying the address is taken. Do not remove the registration at your host first — while your DNS still points there, someone else could register that address with the same host.

1. In banchi, choose Stop connecting and go back to park, and confirm that the connection DNS and TXT records are removed and have propagated.
2. Remove the custom domain at your host, and remove the allowed URLs at your authentication provider and the allowed hostname at Turnstile.
3. Separately remove the ownership verification entry from Verified domains in your GitHub account or organization.

If you cannot remove it, or your banchi address is no longer editable, contact support. Also contact us if you need to resume use.

See the terms for expiry and release timing

What we verified

• GitHub Pages: On September 6, 2026, we used normal banchi screens to acquire an address and save DNS. Ownership verification, enforced HTTPS, search, saving, sharing and file export were tested on Tsunagicho in a real browser.
• Cloudflare Pages: On September 5, 2026, we measured a DNS-only CNAME connection to a different account and HTTPS. The temporary test connections were removed afterward.
• Vercel: Verified end to end on September 7, 2026, in a real browser against a real Vercel project — saving the connection, DNS diagnosis, certificate issuance and removal.
• Netlify: Verified end to end on September 7, 2026, against a real Netlify site — saving the connection, DNS diagnosis, certificate issuance and removal.
• Your own server (VPS): Verified end to end on September 7, 2026, using a GCE e2-micro instance running Caddy with HTTP-01 — saving the connection, DNS diagnosis, certificate issuance and removal.
• Firebase Hosting: Verified end to end on September 10, 2026, against a real Firebase project (Spark free plan) — saving the connection, certificate issuance, "Connected", and removal.
• Google Cloud Run: On September 10, 2026, we tried a direct Domain mapping in the actual Cloud Run UI and confirmed hands-on that it requires Search Console verification of the parent domain. Since banchi.app cannot be verified this way for individual customers, direct mapping is not usable. The Firebase Hosting route (which requires Blaze) was not tested.
• For Vercel, Netlify, your own server, and Firebase Hosting — all four — the connected app's own behavior still needs a separate check.
• Not yet demonstrated: HTTPS to a reachable IPv6 server, dual A/AAAA service, manual DNS-01 issuance and renewal, nginx/Certbot end-to-end setup, migration of individual Worker/R2 applications to Pages, and live connections to AWS Amplify, Azure Static Web Apps, Heroku, or DigitalOcean App Platform (each requires the customer's own account). Configuration examples are based on official documentation. The existing Caddy test did not run until a real renewal became due.

Hosting services can change their requirements. If their instructions differ, check the current official documentation and required record types, then contact us if anything is unclear.

These providers follow the top ten hosting choices in State of JavaScript 2025 (10,704 respondents, multiple selections). This measures hosting experience, not the worldwide market share of solo developers. Broad providers such as AWS are mapped to specific services; Cloudflare has separate Pages and Workers paths. We also cross-checked Stack Overflow 2025. Selection source · Supporting survey

AWS Amplify Hosting

Detailed app setup and connection steps

Conditional; no live banchi connection test yet. Builds and delivery incur usage charges. Stop before saving if verification records outside your rented namespace or nameserver changes are required. A live connection test needs your own AWS account; our 2026-09-10 review did not create a new account or incur new charges for this service.

1. Select the repository and branch in Amplify, check the build command and output directory, then deploy. SSR needs a supported framework setup. Test pages and APIs on the default URL.
2. Open Hosting → Custom domains → Add domain, enter your rented hostname (e.g. your-name.banchi.app) in the domain field, and select Manual configuration.
   Required: Amplify also adds a "www.-prefixed" entry by default and redirects to it. In Rewrites and redirects, decide whether to remove that entry or accept it as an extra name within banchi's five-record limit. Do not register the whole banchi.app domain.
3. In View DNS records, inspect the certificate verification CNAME and the routing CNAME. If every name is your rented hostname or below it, and the total fits five records, save them with banchi's individual DNS editor. Required: Save the verification CNAME soon after adding the domain — Amplify's verification checks become less frequent over time, and a delay can leave it stuck pending.
4. Once Amplify reports a working domain and certificate, test pages, sign-in and APIs at your rented address. Keep the verification CNAME for certificate renewal.

Firebase Hosting

Detailed app setup and connection steps

Verified on September 10, 2026. We tested a real Firebase project (Spark free plan) end to end — saving the connection, certificate issuance, "Connected", and removal. The steps below use Quick setup. This path cannot be used if Firebase asks you to verify the parent banchi.app domain. App Hosting and dynamic API integrations have different billing requirements from Hosting's free tier.

1. Configure Firebase Hosting, set hosting.public in firebase.json to your built static output directory, and deploy. Test the default URL. Dynamic APIs need a separate runtime; App Hosting is also a separate product.
2. In Hosting, select Add custom domain, enter your rented hostname, and choose Quick setup. Note the single CNAME record it shows (pointing at your-site.web.app). No TXT ownership check was requested. If you need the older A/AAAA method, switch to the "Advanced setup" tab.
3. In banchi, choose "Other (CNAME / IPv4 / IPv6)" and save that CNAME as your target value.
4. Wait for Firebase to issue the certificate (about 9.5 minutes in our test). Confirm Connected and a valid certificate, then test pages, sign-in and APIs at your rented address. Check that your authentication settings allow the rented hostname.

Azure Static Web Apps

Detailed app setup and connection steps

Official instructions checked; no live banchi connection test yet. The Free personal plan allows two custom domains. Authentication features or connections to existing APIs may require a paid plan. A live connection test needs your own Azure account; our 2026-09-10 review did not create a new account for this service.

1. Select the repository and branch in Static Web Apps, set app/API source locations and the build output directory, then deploy. Test the default azurestaticapps.net URL. Integrated APIs must use /api, finish within 45 seconds, and cannot use WebSockets.
2. Save your app's default hostname as the root CNAME in banchi's individual DNS editor.
3. In Azure, open Settings → Custom domains → Add → Custom domain on other DNS, enter your rented hostname, and validate using CNAME. If a TXT is requested, confirm its name is inside your rented namespace before adding it.
4. Once validation and automatic HTTPS are complete, test pages, sign-in and APIs at your rented address.

Heroku

Detailed app setup and connection steps

Official instructions checked; no live banchi connection test yet. App compute is paid. Eco costs US$5/month and has limits, including sleeping when idle. A live connection test needs your own Heroku account with a paid plan; our 2026-09-10 review did not create a new account or incur new charges for this service.

1. Configure the web process start command and deploy an app that listens on the PORT environment variable. Test the default URL and check account verification and billing requirements for domains.
2. Add your rented hostname under the app's Settings → Domains and certificates.
3. Copy the supplied DNS Target ending in herokudns.com into the root CNAME in banchi's individual DNS editor. Do not use the app's herokuapp.com URL.
4. Enable Automated Certificate Management (ACM). Once the certificate is valid, test pages, sign-in and APIs at your rented address.

DigitalOcean App Platform

Detailed app setup and connection steps

Conditional; no live banchi connection test yet. App Platform does not support DNSSEC-enabled domains. Check with us before purchasing. Free static hosting has different limits and charges from dynamic apps and transfer. A live connection test needs your own DigitalOcean account; our 2026-09-10 review did not create a new account for this service.

1. Choose Static Site for static files or a paid Web Service for an API. Set the build output directory or run command and HTTP port, then test the default URL. Confirm that the rented address meets the DNSSEC condition.
2. Open Networking → Domains → Add domain, enter your rented hostname, and select You manage your domain.
3. Save the supplied CNAME ending in ondigitalocean.app at the root using banchi's individual DNS editor, then complete Add domain in DigitalOcean.
4. Once the domain and certificate are working, test pages, sign-in and APIs at your rented address.

Google Cloud Run

Detailed app setup and connection steps

Conditional; no live banchi connection test yet (the direct Domain mapping restriction was confirmed hands-on). On 2026-09-10, adding a domain mapping in the actual Cloud Run UI offered only domains verified as a Search Console "Domain" property under that Google account — banchi.app was not among them and could not be selected (confirmed by direct operation, not just documentation). The Firebase Hosting path below was not tested in this review; it still requires Blaze and has a 60-second timeout and cookie restrictions. Consult us before purchasing or adding paid infrastructure.

1. Deploy a Cloud Run service listening on 0.0.0.0 and the PORT environment variable, then test its default URL. Review Cloud Billing and Blaze costs in the same project. Hosting normally forwards only the __session cookie, so check your sign-in design first.
2. Initialize Firebase Hosting. In firebase.json, set hosting.rewrites with the intended public paths and your Cloud Run serviceId and region. Preserve the intended exposure and your application's authentication.
3. Deploy Hosting and test pages, APIs and sign-in at its default web.app or equivalent URL. Requests taking over 60 seconds cannot use this path.
4. Follow the Firebase Hosting instructions to register your rented hostname and save its verification and routing DNS in banchi. Stop if verification of the parent banchi.app domain is requested.
5. Once the certificate is valid, retest pages, sign-in, APIs and saved data at your rented address.