I Turned My Custom Domain Into a Professional Email Address Using iCloud+ — And It Was Surprisingly Easy

How I set up professional business email with Apple iCloud+, Name.com, and GitHub Pages — including a tricky SPF verification issue.

If you’re a freelancer, indie developer, startup founder, or small business owner, you’ve probably wanted a professional email address like:

hello@yourdomain.com

Instead of using something like:

yourbusiness@gmail.com

A custom domain email looks more professional, builds trust, and makes your brand feel more established.

But when you start looking into business email hosting, you’ll quickly come across services like Google Workspace and Microsoft 365, which typically require separate subscriptions.

Recently, I discovered something that made me think:

Wait, I can already do this with my iCloud+ subscription?

And yes, you can!

I decided to try Apple’s Custom Email Domain feature with my own website, wynnsolutionsmyanmar.com, and the experience was surprisingly straightforward.

Here’s how I did it, including one small DNS mistake that prevented Apple from verifying my domain.

1. What Is iCloud+ Custom Email Domain?

Apple’s iCloud+ includes a feature called Custom Email Domain.

It allows you to use a domain you already own to send and receive emails through iCloud Mail.

For example:

• hello@yourdomain.com
• contact@yourdomain.com
• support@yourdomain.com

You can use these email addresses directly from Apple Mail on your iPhone, iPad, or Mac, as well as through iCloud Mail on the web.

The best part?

If you’re already paying for iCloud+, you don’t need another business email hosting subscription for this feature.

Apple supports up to five custom email domains, with up to three personalized email addresses per domain per person.

For a solo developer or small business owner, that’s often more than enough.

One important distinction: multiple email addresses belonging to the same Apple Account share its iCloud Mail inbox. They are not separate employee mailboxes.

2. My Existing Setup

Before configuring iCloud+, here’s what my infrastructure looked like:

Domain registrar: Name.com

Domain: wynnsolutionsmyanmar.com

Website hosting: GitHub Pages

Additional subdomain: Vercel

Email hosting: Not configured yet

My main concern was whether adding iCloud Mail would interfere with my existing website.

Fortunately, websites and email services use different DNS records.

GitHub Pages uses A and CNAME records for web traffic, while iCloud Mail uses MX, TXT, and CNAME records for email routing, verification, and authentication.

This means I could keep my website running on GitHub Pages while using iCloud+ to manage email.

No website migration. No new server. No backend configuration.

Just DNS changes.

3. Setting Up a Custom Email Domain in iCloud+

First, visit:

https://www.icloud.com/icloudplus

Sign in with your Apple Account and find the Custom Email Domain section.

You’ll need an active iCloud+ subscription, two-factor authentication, and iCloud Mail enabled.

Next:

1. Select the option to add a domain you own.
2. Choose whether the domain will be used by you alone or shared with other people.
3. Enter your domain name.
4. Follow Apple’s domain verification instructions.

In my case, I entered:

wynnsolutionsmyanmar.com

If you don’t already have an email address using your domain, that’s fine.

You can create a new custom email address after completing the domain setup. You don’t need to purchase an email mailbox beforehand.

4. Configuring DNS Records on Name.com

This is where things get slightly technical, but it’s manageable.

Since my domain was registered with Name.com and its DNS was managed there, I opened the DNS management dashboard.

Apple provided several DNS records that needed to be added.

Here is an example of the configuration:

Important: Always use the exact DNS values and MX priorities provided by Apple during setup.

The records serve different purposes.

MX records tell other mail servers where to deliver incoming emails.

SPF helps identify which servers are authorized to send email on behalf of your domain.

Domain verification TXT proves that you control the domain.

DKIM helps receiving servers verify that outgoing messages were authorized by your domain and haven’t been altered.

I kept my existing GitHub Pages A records and the CNAME records for my website and subdomain.

Only the email-related DNS configuration needed attention.

If you already use another email provider, changing MX records will redirect incoming email to iCloud. Make sure you plan that migration before replacing existing records.

5. The Problem: Apple Couldn’t Verify My SPF Record

After adding the DNS records, I returned to iCloud+ to finish the setup.

But Apple displayed this message:

Check your SPF record

It suggested checking my DNS configuration and trying again later, since DNS changes can take time to propagate.

At first, everything looked correct in the Name.com dashboard.

My SPF record appeared to be:

"v=spf1 include:icloud.com ~all"

It looked reasonable.

But there was a subtle problem.

Debugging with the Terminal

As a developer, I prefer verifying DNS records directly rather than relying only on a hosting dashboard.

On my Mac, I opened Terminal and ran:

dig @8.8.8.8 TXT wynnsolutionsmyanmar.com +short

The response was:

"\"v=spf1 include:icloud.com ~all\""
"apple-domain=YOUR_VERIFICATION_TOKEN"

Notice the escaped quotation marks?

\"

That was the clue.

The quotation marks had been stored as part of the actual TXT record value, rather than simply being displayed as DNS string delimiters.

As a result, the SPF value did not begin with v=spf1 as required.

The Fix

I went back to Name.com and edited the SPF TXT record.

Instead of entering:

"v=spf1 include:icloud.com ~all"

I entered:

v=spf1 include:icloud.com ~all

Without manually adding quotation marks.

After saving the record, the expected DNS response was:

"v=spf1 include:icloud.com ~all"

Those outer quotation marks are normal in dig output.

The difference is that there are no escaped quotation marks inside the TXT value.

Developer tip: If a DNS verification fails, don’t immediately assume it’s just DNS propagation. Inspect the actual public DNS response.

Also, a domain should publish only one SPF TXT record. If another email service already uses SPF, combine the authorized senders into one valid SPF policy rather than creating multiple SPF records.

6. Creating a Professional Email Address

Once Apple successfully verifies the domain, you can create your custom email addresses.

For my business, useful examples include:

• contact@wynnsolutionsmyanmar.com

You can then send and receive messages through:

https://www.icloud.com/mail

Or use the built-in Mail app on your Apple devices.

No separate email server setup is required.

One thing to keep in mind: iCloud+ Custom Email Domain is especially convenient for personal businesses and small teams already using Apple products.

If you need dedicated employee inboxes, centralized administration, or advanced business collaboration features, Google Workspace or Microsoft 365 may be a better fit.

7. Is iCloud+ Better Than Google Workspace?

It depends on what you need.

FeatureiCloud+Google WorkspaceCustom domain emailYesYesAdditional email hosting subscriptionNot if already subscribed to iCloud+RequiredApple Mail integrationExcellentSupportedSeparate managed employee mailboxesLimitedYesCentralized business administrationLimitedExtensiveBest forIndividuals and small businessesGrowing teams and organizations

For me, the main advantage is simplicity.

I already use Apple devices and iCloud+, so adding custom domain email is a convenient way to make better use of a subscription I’m already paying for.

However, iCloud+ is not a complete replacement for a business email platform in every scenario.

8. A Few Things Worth Knowing

Before using iCloud+ for your own domain, remember:

DNS hosting and domain registration aren’t always the same. Even if you purchased your domain from Name.com, your authoritative DNS could be managed by Cloudflare or another provider.

Email DNS changes don’t require moving your website. Your GitHub Pages or Vercel hosting can remain untouched.

DNS propagation can take time. Some changes become visible quickly, while others take longer depending on caching and provider behavior.

SPF and DKIM matter. Correct authentication improves the reliability of your outgoing email, although it doesn’t guarantee inbox delivery.

DMARC is worth considering. For a business domain, a properly planned DMARC policy provides additional protection against domain spoofing.

Custom email addresses aren’t independent inboxes by default. Multiple addresses assigned to one Apple Account deliver into that account’s iCloud Mail.

Final Thoughts

Sometimes the most useful tools are features we already have but haven’t explored.

I originally thought setting up professional business email would mean subscribing to another service and configuring more infrastructure.

Instead, I discovered that iCloud+ already offered what I needed.

With a few DNS records, some Terminal debugging, and my existing Apple subscription, I could use my own domain for professional email without changing my website hosting.

For indie hackers, freelancers, solo developers, and small business owners who are already in the Apple ecosystem, iCloud+ Custom Email Domain is absolutely worth exploring.

And if Apple tells you to check your SPF record, remember:

Sometimes the problem isn’t the DNS propagation.

Sometimes it’s just two extra quotation marks. 😄

Useful Resources

• Apple — Use Custom Email Domain with iCloud Mail
• iCloud+
• Name.com

Written from my experience setting up custom domain email for Wynn Solutions Myanmar.

Tags: #iCloud #Apple #CustomDomain #EmailHosting #WebDevelopment

Cloudflare ကို website တစ်ခုရဲ့ CDN အနေနဲ့ပဲ သိထားတဲ့ Developer တွေ အများကြီးရှိပါတယ်။

တကယ်တော့ Cloudflare ရဲ့ Developer Platform မှာ —

• Compute → Workers
• Object Storage → R2
• SQL Database → D1
• Key-Value Storage → KV
• Edge Database / Stateful Logic → Durable Objects
• AI → Workers AI
• Deployment & Development CLI → Wrangler

စတဲ့ service တွေရှိပါတယ်။

ဒီ article မှာတော့ အထူးသဖြင့် Wrangler + R2 + D1 ကို အခြေခံပြီး Cloudflare ပေါ်မှာ application တစ်ခုကို ဘယ်လိုတည်ဆောက်နိုင်လဲဆိုတာ လေ့လာကြည့်မယ်။

Wrangler ဆိုတာဘာလဲ?

Wrangler က Cloudflare Workers နဲ့ Cloudflare Developer Platform resources တွေကို command line ကနေ develop, configure, test, deploy လုပ်နိုင်အောင် Cloudflare ကပေးထားတဲ့ CLI tool ဖြစ်ပါတယ်။

အလွယ်ပြောရရင် —

Your Code
    ↓
Wrangler
    ↓
Cloudflare
    ↓
Workers / R2 / D1 / KV / ...

ဆိုတဲ့ workflow ဖြစ်ပါတယ်။

Wrangler နဲ့ —

npx wrangler dev

နဲ့ local development လုပ်နိုင်သလို —

npx wrangler deploy

နဲ့ Worker ကို deploy လုပ်နိုင်ပါတယ်။

Wrangler ကို project ထဲ local dependency အနေနဲ့ install လုပ်ထားဖို့ Cloudflare က အကြံပြုထားပြီး npx wrangler၊ yarn wrangler၊ pnpm wrangler စတဲ့ package-manager based commands တွေကို အသုံးပြုနိုင်ပါတယ်။

R2 ဆိုတာဘာလဲ?

Cloudflare R2 က Object Storage ဖြစ်ပါတယ်။

AWS S3 လိုမျိုး —

Images
Videos
PDFs
Documents
Backups
User Uploads
Static Files

လို binary/file data တွေကို သိမ်းဖို့ အသုံးပြုနိုင်ပါတယ်။

ဥပမာ ကိုယ်က BookWorm လို application တစ်ခုလုပ်နေတယ်ဆိုရင် —

D1
 ├── Users
 ├── Books
 ├── Categories
 └── Reading History

R2
 ├── book-covers/
 ├── illustrations/
 ├── ebooks/
 └── audio/

လို ခွဲထားနိုင်ပါတယ်။

အရေးကြီးတာက D1 နဲ့ R2 ကို အတူတူသုံးနိုင်တယ် ဆိုတာပါ။

Database ထဲမှာ file ကို မသိမ်းဘဲ —

D1
 └── book metadata
      ├── title
      ├── author
      └── cover_url

R2
 └── actual cover image

လို architecture တည်ဆောက်နိုင်ပါတယ်။

D1 ဆိုတာဘာလဲ?

Cloudflare D1 က Cloudflare ရဲ့ SQL database service ဖြစ်ပြီး SQLite ကို အခြေခံထားပါတယ်။

Application ရဲ့ structured data တွေကို သိမ်းဖို့ သုံးနိုင်ပါတယ်။

ဥပမာ —

Users
Products
Orders
Posts
Comments
Reviews
Categories
Reading History

စတာတွေကို D1 ထဲမှာ သိမ်းနိုင်ပါတယ်။

Architecture ကို ရိုးရိုးလေးကြည့်ရင် —

User
  ↓
Cloudflare Worker
  ↓
D1 Database
  ↓
SQL Query

ဖြစ်ပါတယ်။

D1 database ကို Wrangler ကနေ create လုပ်နိုင်ပြီး database ကို Worker ထဲမှာ binding အဖြစ် ချိတ်ဆက်အသုံးပြုနိုင်ပါတယ်။

R2 + D1 ကို ဘာကြောင့် အတူသုံးမလဲ?

ဒီနှစ်ခုရဲ့ role မတူပါဘူး။

D1

Structured data အတွက် —

User
Product
Order
Book
Category
Review

R2

Files / Objects အတွက် —

Image
PDF
Video
Audio
ZIP
Document

ဆိုပြီး စဉ်းစားနိုင်ပါတယ်။

ဥပမာ e-commerce application တစ်ခုဆိုရင် —

Cloudflare Worker
                       │
              ┌────────┴────────┐
              ↓                 ↓
             D1                 R2
       Structured Data       Object Storage
              │                 │
        ┌─────┼─────┐       ┌───┼────┐
        │     │     │       │   │    │
      Users Products Orders Images PDFs

ဒီ architecture က serverless application တွေအတွက် အတော်လေး practical ဖြစ်ပါတယ်။

အရင်ဆုံး Wrangler Install လုပ်မယ်

Node.js project တစ်ခုရှိတယ်ဆိုရင် —

npm install -D wrangler

ပြီးရင် —

npx wrangler --version

နဲ့ version စစ်နိုင်ပါတယ်။

Cloudflare account ကို authenticate လုပ်ချင်ရင် —

npx wrangler login

ကို အသုံးပြုနိုင်ပါတယ်။

Worker Project တည်ဆောက်မယ်

Project အသစ်တစ်ခုစဖို့ —

npm create cloudflare@latest my-app

ပြီးရင် project folder ထဲဝင်ပါ။

cd my-app

Local development စဖို့ —

npx wrangler dev

ဒါဆို local development server တစ်ခု run နေပါလိမ့်မယ်။

D1 Database တည်ဆောက်မယ်

Database အသစ်တစ်ခု create လုပ်ဖို့ —

npx wrangler d1 create my-app-db

ဒီ command က D1 database အသစ်တစ်ခု create လုပ်ပေးပြီး Worker configuration ထဲမှာ အသုံးပြုမယ့် database binding နဲ့ ID ကို ရရှိစေပါတယ်။

ပြီးရင် application ရဲ့ configuration မှာ D1 binding ကို ချိတ်ပေးနိုင်ပါတယ်။

ဥပမာ —

{
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "my-app-db",
      "database_id": "YOUR_DATABASE_ID"
    }
  ]
}

ဒီလို binding လုပ်ထားရင် Worker code ထဲမှာ —

env.DB

ကနေ database ကို access လုပ်နိုင်ပါတယ်။

Table တစ်ခု Create လုပ်ကြည့်မယ်

ဥပမာ users table —

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

Local database မှာ run ချင်ရင် —

npx wrangler d1 execute my-app-db \
  --file=./schema.sql \
  --local

Remote database မှာ run ချင်ရင် —

npx wrangler d1 execute my-app-db \
  --file=./schema.sql \
  --remote

Wrangler ရဲ့ D1 command တွေမှာ local နဲ့ remote database နှစ်မျိုးလုံးကို ခွဲပြီး execute လုပ်နိုင်ပါတယ်။

D1 Migration သုံးမယ်

Production project ဖြစ်လာရင် SQL ကို တစ်ခါတည်း manually run တာထက် migrations သုံးတာ ပိုကောင်းပါတယ်။

Migration အသစ် create လုပ်ဖို့ —

npx wrangler d1 migrations create my-app-db create-users

ပြီးရင် migration file ထဲမှာ —

CREATE TABLE users (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL
);

လိုရေးနိုင်ပါတယ်။

Migration apply လုပ်ဖို့ —

npx wrangler d1 migrations apply my-app-db

ဖြစ်ပါတယ်။

ဒီလို version-controlled database schema workflow သုံးနိုင်တာက team development နဲ့ CI/CD အတွက် အသုံးဝင်ပါတယ်။

R2 Bucket တည်ဆောက်မယ်

အခု file storage အတွက် R2 bucket တစ်ခု create လုပ်မယ်။

npx wrangler r2 bucket create my-app-files

Bucket list ကြည့်ချင်ရင် —

npx wrangler r2 bucket list

Cloudflare ရဲ့ လက်ရှိ Wrangler R2 commands တွေက bucket create, list နဲ့ object management တွေအတွက် အသုံးပြုနိုင်ပါတယ်။

Worker ထဲမှာ R2 Binding ချိတ်မယ်

ဥပမာ configuration မှာ —

{
  "r2_buckets": [
    {
      "binding": "FILES",
      "bucket_name": "my-app-files"
    }
  ]
}

လို binding ချိတ်နိုင်ပါတယ်။

ပြီးရင် Worker code ထဲမှာ —

env.FILES

ကနေ R2 bucket ကို access လုပ်နိုင်ပါတယ်။

File Upload လုပ်ကြည့်မယ်

ဥပမာ Worker endpoint တစ်ခုမှာ —

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (request.method === "PUT" && url.pathname.startsWith("/upload/")) {
      const key = url.pathname.replace("/upload/", "");

      await env.FILES.put(key, request.body);

      return new Response("Uploaded");
    }

    return new Response("Hello World");
  }
};

ဒီလိုရေးထားရင် —

PUT /upload/profile.jpg

ဆိုတဲ့ request ကနေ R2 ထဲမှာ —

profile.jpg

ဆိုတဲ့ object တစ်ခု သိမ်းနိုင်ပါတယ်။

Cloudflare Workers က R2 bucket ကို binding လုပ်ထားတဲ့အခါ Workers API ကနေ objects တွေကို read/write လုပ်နိုင်ပါတယ်။

R2 Object ကို Read လုပ်မယ်

Upload လုပ်ထားတဲ့ file ကို ပြန်ဖတ်ချင်ရင် —

const object = await env.FILES.get("profile.jpg");

if (!object) {
  return new Response("Not Found", {
    status: 404
  });
}

return new Response(object.body, {
  headers: {
    "Content-Type": object.httpMetadata?.contentType || "application/octet-stream"
  }
});

ဒီလို R2 object ကို Worker ကနေ directly retrieve လုပ်နိုင်ပါတယ်။

D1 + R2 ကို Application တစ်ခုထဲမှာ တွဲသုံးမယ်

ဒီအပိုင်းက တကယ်အသုံးဝင်ပါတယ်။

ဥပမာ user profile system တစ်ခုလုပ်မယ်ဆိုပါစို့။

User ရဲ့ information ကို D1 မှာ —

users
-------------------------
id
name
email
avatar_key

Avatar image ကို R2 မှာ —

avatars/
    user-123.jpg

လို သိမ်းနိုင်ပါတယ်။

Request တစ်ခုလာတဲ့အခါ —

Client
   │
   ▼
Worker
   │
   ├───────────────┐
   ▼               ▼
  D1               R2
   │               │
User Metadata    Avatar

ဆိုတဲ့ architecture ဖြစ်လာပါတယ်။

Real-world Example: Blog Platform

Tech Articles page တစ်ခုလုပ်တယ်လို့ ယူဆကြည့်မယ်။

D1 မှာ —

articles
-------------------------
id
title
slug
content
author_id
published_at

R2 မှာ —

article-images/
    cloudflare-tunnel.png
    wrangler-r2-d1.png
    serverless.png

လို သိမ်းထားနိုင်ပါတယ်။

API request တစ်ခု —

GET /api/articles/cloudflare-tunnel

ဝင်လာရင် Worker က —

Request
   ↓
Worker
   ↓
D1
   ↓
Article Metadata
   ↓
R2
   ↓
Cover Image
   ↓
JSON Response

လို workflow နဲ့ response ပြန်နိုင်ပါတယ်။

Wrangler က Development ကို ဘာကြောင့် လွယ်စေတာလဲ?

ပုံမှန် application development မှာ —

Code
 ↓
Server
 ↓
Database
 ↓
Object Storage
 ↓
Deployment

တစ်ခုချင်းစီကို သီးခြား configure လုပ်ရတတ်ပါတယ်။

Cloudflare ecosystem မှာတော့ Wrangler က ဒီ resources တွေကို CLI တစ်ခုထဲကနေ manage လုပ်နိုင်အောင် ကူညီပေးပါတယ်။

Wrangler
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Worker         D1           R2
       │            │            │
    Compute      Database     Storage

ဒါကြောင့် project configuration ကို code repository ထဲမှာ ထည့်ထားပြီး repeatable development/deployment workflow တည်ဆောက်နိုင်ပါတယ်။

Local Development မှာလည်း R2 + D1 စမ်းလို့ရတယ်

Cloudflare application တစ်ခုကို production မတင်ခင် local မှာ test လုပ်နိုင်တာက အရေးကြီးပါတယ်။

D1 အတွက် —

npx wrangler d1 execute my-app-db \
  --command="SELECT * FROM users" \
  --local

လို local database ကို query လုပ်နိုင်ပါတယ်။

R2 object တွေကိုလည်း local development environment မှာ စမ်းသပ်နိုင်ပါတယ်။ Cloudflare ရဲ့ local-development documentation မှာ R2 object operations နဲ့ D1 SQL operations တွေအတွက် local mode ကို ဖော်ပြထားပါတယ်။

Database Backup / Export

D1 database ကို SQL file အဖြစ် export လုပ်ချင်ရင် —

npx wrangler d1 export my-app-db \
  --remote \
  --output=backup.sql

လိုလုပ်နိုင်ပါတယ်။

Table တစ်ခုချင်းစီ export လုပ်တာ၊ schema ပဲ export လုပ်တာ၊ data ပဲ export လုပ်တာမျိုးလည်း Wrangler ရဲ့ D1 export command မှာ support လုပ်ထားပါတယ်။

Production Architecture

နောက်ဆုံးမှာ application architecture က ဒီလိုမျိုး ဖြစ်လာနိုင်ပါတယ် —

Internet
                       │
                       ▼
               Cloudflare Network
                       │
                       ▼
                    Worker
                       │
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
             D1                 R2
        SQL Database        Object Storage
              │                 │
       ┌──────┼──────┐      ┌───┼────┐
       │      │      │      │   │    │
     Users  Posts  Orders  Images PDFs

ဒီ architecture မှာ —

Worker
→ Business logic / API / routing

D1
→ Structured relational data

R2
→ Files / Objects

ဆိုပြီး responsibility ကို ခွဲထားနိုင်ပါတယ်။

Wrangler + R2 + D1 ကို ဘယ်အချိန်မှာ သုံးမလဲ?

RequirementCloudflare ServiceAPI / Backend LogicWorkersCLI / DeploymentWranglerSQL DatabaseD1Images / FilesR2Key-Value DataKVStateful coordinationDurable ObjectsTemporary Local → Public URLTryCloudflare

ဒါကြောင့် Cloudflare ကို CDN တစ်ခုအဖြစ်ပဲ မမြင်ဘဲ Application Platform တစ်ခုအဖြစ် စဉ်းစားနိုင်ပါတယ်။

အရေးကြီးတဲ့ Concept တစ်ခု

Application တစ်ခုတည်ဆောက်တဲ့အခါ data အားလုံးကို database တစ်ခုထဲ ထည့်ဖို့ မလိုပါဘူး။

ဥပမာ —

Application
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
         D1         R2        KV
          │          │          │
       Structured   Files    Fast/Small
         Data      Objects      Data

ဒီလို data type အလိုက် storage ကို ခွဲသုံးတာ က scalable architecture တည်ဆောက်ရာမှာ အရေးကြီးတဲ့ concept တစ်ခုပါ။

Conclusion

Wrangler + R2 + D1 ကို နားလည်ထားရင် Cloudflare ပေါ်မှာ serverless application တစ်ခုတည်ဆောက်ဖို့ အခြေခံ architecture ကို စတင်နားလည်နိုင်ပါပြီ။

အဓိကမှတ်ထားရမယ့် concept က —

Wrangler
   ↓
Manage / Develop / Deploy

Worker
   ↓
Run Application Logic

D1
   ↓
Store Structured Data

R2
   ↓
Store Files / Objects

ပြီးတော့ real-world application တစ်ခုမှာ —

User
 ↓
Cloudflare Worker
 ↓
 ├── D1 → Users / Posts / Orders
 │
 └── R2 → Images / PDFs / Videos

ဆိုတဲ့ architecture တစ်ခုတည်ဆောက်နိုင်ပါတယ်။

အထူးသဖြင့် API + Database + File Storage ပါတဲ့ modern web application တစ်ခုကို traditional server တစ်လုံးကို အဓိကထားမနေဘဲ Cloudflare Developer Platform ပေါ်မှာ တည်ဆောက်ချင်တဲ့ Developer တွေအတွက် ဒီ architecture က စိတ်ဝင်စားစရာကောင်းတဲ့ approach တစ်ခုပါ။

နောက်တစ်ဆင့်အနေနဲ့ —

npx wrangler dev
npx wrangler d1 create my-db
npx wrangler r2 bucket create my-files
npx wrangler deploy

ဆိုတဲ့ commands တွေကနေ စပြီး ကိုယ့်ရဲ့ ပထမဆုံး Cloudflare application ကို တည်ဆောက်ကြည့်နိုင်ပါတယ်။

#Cloudflare #Wrangler #CloudflareWorkers #CloudflareR2 #CloudflareD1 #Serverless #ServerlessArchitecture #WebDevelopment #BackendDevelopment #APIDevelopment #JavaScript #TypeScript #SQL #SQLite #ObjectStorage #CloudComputing #DeveloperTools #DevOps #CloudDevelopment #SoftwareEngineering #TechMyanmar #MyanmarDevelopers #WynnSolutionsMyanmar

Developer တစ်ယောက်အနေနဲ့ local မှာ run နေတဲ့ application ကို တခြားသူတစ်ယောက်ဆီ ခဏ share ချင်တဲ့အချိန်တွေ ရှိတတ်ပါတယ်။

ဥပမာ —

• Client ကို development version demo ပြချင်တာ
• Mobile phone ကနေ localhost website ကို test လုပ်ချင်တာ
• Webhook endpoint ကို local machine မှာ test လုပ်ချင်တာ
• Frontend developer နဲ့ backend API ကို ခဏ share ချင်တာ
• QA tester ကို local build တစ်ခု access ပေးချင်တာ

ပုံမှန်ဆိုရင် server တင်မယ်၊ domain/subdomain configure လုပ်မယ်၊ SSL setup လုပ်မယ်ဆိုပြီး အဆင့်တွေအများကြီး လိုနိုင်ပါတယ်။

ဒီလို development/testing use case တွေအတွက် Cloudflare မှာ TryCloudflare / Quick Tunnels ဆိုတဲ့ အလွန်အသုံးဝင်တဲ့ feature တစ်ခုရှိပါတယ်။

TryCloudflare ဆိုတာဘာလဲ?

TryCloudflare ဟာ Cloudflare Tunnel ရဲ့ Quick Tunnel feature ဖြစ်ပါတယ်။

ကိုယ့် computer ထဲမှာ

http://localhost:3000

လို run နေတဲ့ application တစ်ခုကို

https://random-name.trycloudflare.com

လို public HTTPS URL တစ်ခုနဲ့ Internet ကနေ access လုပ်နိုင်အောင် expose လုပ်ပေးနိုင်ပါတယ်။

အထူးသဖြင့် Quick Tunnel သုံးဖို့အတွက် Cloudflare account မလိုပါဘူး။ ကိုယ်ပိုင် domain လည်း မလိုပါဘူး။ DNS records configure လုပ်စရာလည်း မလိုပါဘူး။

လိုအပ်တာက cloudflared နဲ့ local မှာ run နေတဲ့ service တစ်ခုပဲ ဖြစ်ပါတယ်။

ဘယ်လိုအလုပ်လုပ်သလဲ?

Architecture ကို အလွယ်ကြည့်မယ်ဆိုရင် —

User / Client
     │
     │ HTTPS
     ▼
Cloudflare Network
     │
     │ Cloudflare Tunnel
     ▼
 cloudflared
     │
     ▼
localhost:3000
     │
     ▼
Your Application

ဒီနေရာမှာ အရေးကြီးတဲ့အချက်က router မှာ port forwarding လုပ်ပြီး local machine ကို တိုက်ရိုက် Internet ပေါ် expose လုပ်တာ မဟုတ်ပါဘူး။

cloudflared က ကိုယ့် machine ကနေ Cloudflare network ဆီကို outbound connection စတင်တည်ဆောက်ပေးတာပါ။ Cloudflare Tunnel ရဲ့ architecture က inbound port ဖွင့်စရာမလိုဘဲ origin service ကို Cloudflare network နဲ့ ချိတ်ဆက်နိုင်အောင် design လုပ်ထားပါတယ်။

ဥပမာ user က

https://example-random.trycloudflare.com

ကို request လုပ်လိုက်ရင် traffic flow က အကြမ်းဖျင်းအားဖြင့်

Browser
   ↓
Cloudflare Edge
   ↓
Encrypted Tunnel
   ↓
cloudflared
   ↓
localhost:3000

ဖြစ်သွားပါတယ်။

Setup လုပ်ကြည့်မယ်

ပထမဆုံး cloudflared ကို install လုပ်ရပါမယ်။

macOS မှာ Homebrew သုံးထားရင် —

brew install cloudflared

ပြီးရင် ကိုယ့် application ကို ပုံမှန်အတိုင်း run ထားပါ။

ဥပမာ Node.js / React / Laravel / WordPress development server တစ်ခုက

http://localhost:8080

မှာ run နေတယ်ဆိုပါစို့။

Quick Tunnel စဖို့ command တစ်ကြောင်းပဲ လိုပါတယ်။

cloudflared tunnel --url http://localhost:8080

Run လိုက်တဲ့အခါ cloudflared က random trycloudflare.com hostname တစ်ခု generate လုပ်ပေးပါလိမ့်မယ်။

ဥပမာ —

https://random-words-example.trycloudflare.com

အဲဒီ URL ကို browser ကနေဖွင့်လိုက်ရင် ကိုယ့် localhost:8080 မှာ run နေတဲ့ application ကို Internet ကနေ access လုပ်နိုင်ပါပြီ။

Development Workflow မှာ ဘယ်နေရာတွေ အသုံးဝင်လဲ?

Client Demo

Project ကို production/staging server မတင်ရသေးပေမယ့် client ကို progress ပြချင်တယ်ဆိုပါစို့။

npm run dev

ပြီးရင် —

cloudflared tunnel --url http://localhost:5173

Client ဆီကို generated URL ပေးလိုက်ရုံပါပဲ။

Frontend changes လုပ်လိုက်တိုင်း local server မှာ reflect ဖြစ်ပြီး tunnel ကတစ်ဆင့် client ဘက်ကလည်း မြင်နိုင်ပါတယ်။

Mobile Testing

Desktop မှာ development လုပ်နေတဲ့ website ကို actual phone ကနေ စမ်းချင်ရင်လည်း အသုံးဝင်ပါတယ်။

localhost:3000
       ↓
Cloudflare Tunnel
       ↓
https://random.trycloudflare.com
       ↓
iPhone / Android

Local network IP တွေ configure လုပ်နေစရာမလိုဘဲ public URL ကို phone browser ကနေ တန်းဖွင့်နိုင်ပါတယ်။

Webhook Testing

Webhook development မှာ ပိုပြီးအသုံးဝင်ပါတယ်။

ဥပမာ local API က —

http://localhost:8000/api/webhook

ဆိုရင် Quick Tunnel ဖွင့်ပြီးနောက် —

https://random.trycloudflare.com/api/webhook

လို public endpoint ရလာနိုင်ပါတယ်။

ဒါကို third-party service ရဲ့ webhook URL အဖြစ် development/testing အတွက် သုံးနိုင်ပါတယ်။

QA Testing

Developer machine မှာ run နေတဲ့ build ကို QA tester ဆီပေးချင်ရင် staging deployment မလုပ်ခင် Quick Tunnel နဲ့ အမြန် share လုပ်နိုင်ပါတယ်။

ဒါကြောင့် development cycle မှာ

Developer
    ↓
Local App
    ↓
TryCloudflare
    ↓
QA / Client / Teammate

ဆိုတဲ့ workflow လုပ်နိုင်ပါတယ်။

Access ကို Email နဲ့ Restrict လုပ်ခြင်း

Quick Tunnel ရဲ့ စိတ်ဝင်စားစရာကောင်းတဲ့ လက်ရှိ feature တစ်ခုက email authentication ပါ။

Public URL ရသွားတဲ့သူတိုင်း ဝင်ကြည့်နိုင်တာမျိုး မဖြစ်စေချင်ဘူးဆိုရင် —

cloudflared tunnel \
  --url http://localhost:8080 \
  --allowed-mail alice@example.com

လို run နိုင်ပါတယ်။

Visitor က URL ကိုဝင်တဲ့အခါ email authentication လုပ်ရပြီး email ဆီပို့တဲ့ one-time PIN နဲ့ authenticate လုပ်ပြီးမှ local application ကို access ရမှာပါ။ Multiple email addresses နဲ့ domain-level allowance တွေလည်း configure လုပ်နိုင်ပါတယ်။

ဒါက temporary client demos နဲ့ internal previews တွေအတွက် တော်တော်အသုံးဝင်ပါတယ်။

Security အရ ဘာကောင်းသလဲ?

Traditional approach မှာ —

Internet
   ↓
Public IP
   ↓
Open Port
   ↓
Local Server

လိုမျိုး ဖြစ်နိုင်ပါတယ်။

Cloudflare Tunnel architecture ကတော့ origin ကနေ Cloudflare ဆီ outbound connection စလုပ်တာဖြစ်တဲ့အတွက် inbound port ဖွင့်စရာ၊ public origin IP expose လုပ်စရာ မလိုပါဘူး။

ဒါပေမယ့် Quick Tunnel URL ကို public ထုတ်ထားရင် URL သိတဲ့သူက application ကို access လုပ်နိုင်တာကို သတိထားရပါမယ်။ Sensitive development environment ဖြစ်ရင် email restriction သုံးတာ ဒါမှမဟုတ် proper Cloudflare Access configuration ပါတဲ့ named tunnel သုံးတာ ပိုသင့်တော်ပါတယ်။

TryCloudflare ကို Production မှာ သုံးသင့်လား?

မသုံးသင့်ပါဘူး။

Cloudflare ကိုယ်တိုင်က Quick Tunnels ကို testing နဲ့ development အတွက် ရည်ရွယ်ထားတယ်လို့ documentation မှာ ရှင်းရှင်းလင်းလင်း ဖော်ပြထားပါတယ်။

Quick Tunnel မှာ —

• uptime guarantee မရှိပါ
• tunnel အသစ်ပြန်စတိုင်း hostname ပြောင်းနိုင်ပါတယ်
• တစ်ချိန်တည်းမှာ in-flight requests 200 အထိ limitation ရှိပါတယ်
• limit ကျော်သွားရင် HTTP 429 ရနိုင်ပါတယ်
• Server-Sent Events (SSE) မထောက်ပံ့ပါ

ဆိုတဲ့ limitations တွေ ရှိပါတယ်။

Production environment အတွက်တော့ account နဲ့ domain configure လုပ်ထားတဲ့ proper Cloudflare Tunnel / Named Tunnel ကို သုံးသင့်ပါတယ်။ အဲဒီမှာ stable hostname တစ်ခုကို local service နဲ့ map လုပ်နိုင်ပါတယ်။

Quick Tunnel vs Production Cloudflare Tunnel

FeatureQuick TunnelNamed / Production TunnelCloudflare AccountမလိုလိုOwn DomainမလိုလိုURLRandom trycloudflare.comကိုယ်ပိုင် hostnameSetupအလွန်မြန်Configuration လိုStable URLမဟုတ်ဟုတ်Productionမသင့်သင့်Best UseDev / Demo / TestingProduction / Staging

Quick Tunnel ကို တစ်ခါသုံး preview environment လို့ စဉ်းစားနိုင်ပြီး Named Tunnel ကို long-running infrastructure အတွက် သုံးတာ ပိုသင့်တော်ပါတယ်။

ngrok နဲ့ Concept တူလား?

Concept အရတော့ တူပါတယ်။

နှစ်ခုစလုံးရဲ့ common development use case က —

localhost
   ↓
Tunnel
   ↓
Public HTTPS URL

ဖြစ်ပါတယ်။

TryCloudflare ရဲ့ အားသာချက်က Cloudflare ecosystem ကိုသုံးနေတဲ့ developer တွေအတွက် Cloudflare Tunnel architecture နဲ့ တိုက်ရိုက်ချိတ်ဆက်ပြီး စမ်းနိုင်တာပါ။

အထူးသဖြင့် account/domain setup မလုပ်ချင်သေးတဲ့အချိန်

cloudflared tunnel --url http://localhost:8080

command တစ်ကြောင်းနဲ့ public development URL ရနိုင်တာက အလွန်အဆင်ပြေပါတယ်။

2026 မှာ Wrangler ကနေလည်း Quick Tunnel ဖွင့်နိုင်ပြီ

Cloudflare ရဲ့ newer developer tooling မှာ Wrangler ကနေ Quick Tunnel စနိုင်တဲ့ command လည်း ရှိလာပါတယ်။

npx wrangler tunnel quick-start http://localhost:8080

ဒါကလည်း temporary random *.trycloudflare.com URL တစ်ခုထုတ်ပေးပါတယ်။ Quick Tunnel က process run နေတဲ့အချိန်အတွင်းပဲ အသက်ဝင်နေမှာ ဖြစ်ပါတယ်။

Wrangler/Vite development workflow တွေမှာလည်း local dev session ကို Tunnel ကတစ်ဆင့် share လုပ်နိုင်တဲ့ integration တွေ ထပ်တိုးလာပါတယ်။

Conclusion

TryCloudflare ဟာ feature ကြီးကြီးမားမားတစ်ခုလို ထင်ရပေမယ့် developer workflow ထဲမှာတော့ အတော်လေး practical ဖြစ်ပါတယ်။

အထူးသဖြင့် —

Local Development
       ↓
Need Public Access
       ↓
cloudflared Quick Tunnel
       ↓
*.trycloudflare.com
       ↓
Client / QA / Mobile / Webhook

ဆိုတဲ့ workflow ကို server deployment မလုပ်ဘဲ မိနစ်ပိုင်းအတွင်း တည်ဆောက်နိုင်ပါတယ်။

စမ်းကြည့်ချင်ရင် အဓိကမှတ်ထားရမယ့် command က တစ်ကြောင်းပဲရှိပါတယ်။

cloudflared tunnel --url http://localhost:8080

ဒါနဲ့ ကိုယ့် localhost က application တစ်ခုကို temporary public HTTPS endpoint တစ်ခုအဖြစ် ပြောင်းနိုင်ပါတယ်။

TryCloudflare ဟာ production hosting replacement မဟုတ်ပါဘူး။ ဒါပေမယ့် local development, temporary demos, QA testing နဲ့ webhook development အတွက် developer toolbox ထဲမှာ ထည့်ထားသင့်တဲ့ utility တစ်ခုဖြစ်ပါတယ်။

Official references အနေနဲ့ Cloudflare Quick Tunnels Documentation နဲ့ Cloudflare Tunnel Documentation ကို ဆက်ဖတ်နိုင်ပါတယ်။

#Cloudflare #TryCloudflare #CloudflareTunnel #QuickTunnel #CloudflareWorkers #DevTools #WebDevelopment #SoftwareEngineering #DeveloperTools #DevOps #Networking #Localhost #Webhook #APIDevelopment #CloudComputing #HTTPS #CyberSecurity #CloudflareDevelopers #TechMyanmar #MyanmarDevelopers
#WynnSolutionsMyanmar

You’ve got a Node.js API on your Mac and a Flutter app on a real iOS device. You want them to talk smoothly over the same Wi-Fi or from anywhere via ngrok.

Here’s a clean, copy-pasteable setup that just works.

What you’ll build

• A minimal Express API (served with pnpm)
• Reachable from your iPhone either:
• A. Directly over your LAN (using your Mac’s IP), or
• B. Via a public ngrok HTTPS URL (no IP juggling, ATS-friendly)
• Flutter app using Riverpod + Dio that calls /health and shows the response.

Prerequisites

• macOS with Node.js ≥ 18 and pnpm
• Flutter SDK installed, Xcode set up for iOS
• An iPhone on the same Wi-Fi (for the LAN option)
• An ngrok account (free is fine) for the ngrok option

Part 1 — Express API (pnpm)

1. Scaffold & install

mkdir mac-express-api && cd mac-express-api
pnpm init -y
pnpm add express cors
pnpm add -D nodemon

in the package.json — add scripts:

{
  "name": "mac-express-api",
  "version": "1.0.0",
  "main": "src/server.js",
  "scripts": {
    "dev": "nodemon --watch src --ext js,json src/server.js"
  },
  "dependencies": {
    "cors": "^2.8.5",
    "express": "^4.19.2"
  },
  "devDependencies": {
    "nodemon": "^3.1.0"
  }
}

2. Minimal server bound to all interfaces

src/server.js

const express = require('express');
const cors = require('cors');

const app = express();
app.use(express.json());

// Keep CORS wide open for dev; tighten later if needed
app.use(cors({ origin: true }));

app.get('/health', (req, res) => {
  res.json({ ok: true, time: new Date().toISOString() });
});

const PORT = process.env.PORT || 3000;

// IMPORTANT: bind to 0.0.0.0 so devices on your network (or ngrok) can reach it
app.listen(PORT, '0.0.0.0', () => {
  console.log(`API listening on http://0.0.0.0:${PORT}`);
});

Run it:

pnpm dev

Part 2 — Choose how the iPhone reaches your API

Option A) Direct LAN (same Wi-Fi)

1. Find your Mac’s IP:

ipconfig getifaddr en0   # usually Wi-Fi; example: 192.168.1.23

2. Test from your iPhone’s Safari:

http://192.168.1.23:3000/health

If you see JSON, you’re good.

If it doesn’t load, check macOS Firewall (System Settings → Network → Firewall → allow Node/nodemon) and ensure your router doesn’t enable AP/client isolation.

iOS ATS for HTTP on LAN

iOS blocks plain HTTP by default. For development, add an exception:

ios/Runner/Info.plist:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>192.168.1.23</key>
    <dict>
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key><true/>
    </dict>
  </dict>
</dict>

(Change 192.168.1.23 to your IP.)

Option B) ngrok (recommended, HTTPS out of the box)

1. Install & authenticate ngrok (grab your authtoken from the ngrok dashboard):

ngrok config add-authtoken <YOUR_AUTHTOKEN>

2. Expose your local API:

ngrok http 3000

3. Copy the HTTPS forwarding URL, e.g. https://exampleforwardingurl.ngrok.io

This works from anywhere, not just your Wi-Fi.

Because it’s real HTTPS, iOS ATS is happy — no Info.plist exceptions needed.

Free ngrok URLs rotate when you restart. For a stable URL, reserve a domain (paid).

Part 3 — Flutter (Riverpod) wiring

Add dependencies:

flutter pub add flutter_riverpod dio

We’ll make the base URL configurable via --dart-define, so you can swap between LAN IP and ngrok quickly.

1. Base URL provider (Riverpod)

ngrok config add-authtoken <YOUR_AUTHTOKEN>

2. Dio provider

lib/core/network/dio_provider.dart

import 'package:dio/dio.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'base_url.dart';

final dioProvider = Provider<Dio>((ref) {
  final baseUrl = ref.watch(baseUrlProvider);
  return Dio(BaseOptions(
    baseUrl: baseUrl,
    connectTimeout: const Duration(seconds: 10),
    receiveTimeout: const Duration(seconds: 20),
  ));
});

3. Simple repo + provider

lib/features/health/health_repo.dart

import 'package:dio/dio.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import '../../core/network/dio_provider.dart';

final healthRepoProvider = Provider<HealthRepo>((ref) {
  final dio = ref.watch(dioProvider);
  return HealthRepo(dio);
});

class HealthRepo {
  final Dio _dio;
  HealthRepo(this._dio);

  Future<Map<String, dynamic>> getHealth() async {
    final res = await _dio.get('/health');
    return Map<String, dynamic>.from(res.data);
  }
}

lib/features/health/health_provider.dart

import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'health_repo.dart';

final healthProvider = FutureProvider<Map<String, dynamic>>((ref) async {
  final repo = ref.watch(healthRepoProvider);
  return repo.getHealth();
});

4. A tiny UI to verify

lib/features/health/health_screen.dart

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'health_provider.dart';

class HealthScreen extends ConsumerWidget {
  const HealthScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final asyncHealth = ref.watch(healthProvider);
    return Scaffold(
      appBar: AppBar(title: const Text('Health Check')),
      body: Center(
        child: asyncHealth.when(
          data: (d) => Text('OK: ${d['ok']} at ${d['time']}'),
          loading: () => const CircularProgressIndicator(),
          error: (e, _) => Text('Error: $e'),
        ),
      ),
    );
  }
}

Hook it up as your home widget (e.g., in main.dart) and don’t forget ProviderScope.

Part 4 — Run the whole thing

A) Using LAN IP (same Wi-Fi)

1. Start the API:

pnpm dev

2. Verify from iPhone Safari:

http://<YOUR_MAC_IP>:3000/health

3. Run Flutter to the real device (with your IP):

flutter run --dart-define=API_BASE_URL=http://192.168.1.23:3000

If iOS throws ATS errors, add the Info.plist exception shown above.

B) Using ngrok (recommended)

1. Start the API:

pnpm dev

2. Start ngrok:

ngrok http 3000

3. Use the HTTPS URL for Flutter:

flutter run --dart-define=API_BASE_URL=https://exampleforwardingurl.ngrok.io

No ATS changes needed — ngrok is HTTPS. Your app will work even off your home Wi-Fi.

Troubleshooting Cheatsheet

Can’t reach server from iPhone (LAN)

• net; WLAN AP/client isolation disabled
• macOS Firewall allows Node/nodemon
• Same SSID/subnet; WLAN AP/client isolation disabled

ATS blocked (only on HTTP to LAN IP)

• Add the NSExceptionDomains entry in Info.plist, or use ngrok HTTPS to avoid ATS exceptions entirely.

ngrok URL changes every run

• That’s normal on free plans. Consider a reserved domain for a stable URL.

CORS errors

• Native Flutter apps (Dio) aren’t subject to browser CORS. If you also open the API in a web browser, keep cors({ origin: true }) during dev.

Simulator vs Real Device

• Simulator can often use http://localhost. Real devices must use LAN IP or ngrok.

Optional: Environment presets

For convenience, create run configs:

LAN dev:

flutter run --dart-define=API_BASE_URL=http://192.168.1.23:3000

ngrok dev:

flutter run --dart-define=API_BASE_URL=https://abc123.ngrok.io

Or add them to launch.json in VS Code, or make simple shell scripts.

Wrap-up

That’s it — a clean Express API served via pnpm, reachable by a Flutter (Riverpod) iOS app over your LAN or through a secure ngrok URL. Use LAN for super-low latency on the same Wi-Fi, and flip to ngrok when you leave your network or want an ATS-friendly HTTPS endpoint with zero extra config.

သူအင်ဂျင်နီယာတက္ကသလိုလ်ဆင်းတဲ့ အင်ဂျင်နီယာ မဖြစ်ခဲ့လို့ သားနှစ်ယောက်လုံးကို အင်ဂျင်နီယာကျောင်းရအောင် ထားပေးခဲ့တယ်။

အကုန်ပြည့်စုံပြီလို့ထင်ရတဲ့အချိန် ကိုဗစ်ကြောင့် သူထားခဲ့တယ်။ ဒီနေ့ မေ၂၂ အိပ်မက်မက်တယ် ဖေဖေလေ အိမ်ပြန်လာတာ ကားဂိတ်မှာသွားစောင့်ပေးတာတဲ့ ကိုယ့်ရှေ့မှာ ကလေးတစ်ယောက်က ဈေးဝယ်ချင်တာ သူ့အဖေရှာနေတာတဲ့ ကိုယ့်စိတ်ထဲတော့ ကိုယ်လဲ အဖေပြန်အလာ လာကြိုတာပေါ့​ရေခဲထုပ်လေးစားရင်းနဲ့ ကားလမ်းကူးလိုက်တာ ကားပေါ်ပါသွားလို့ ဖေဖေနဲ့လွဲသွားတယ် အိမ်မက်ထဲမှာတောင် ဝေဝေဝါးဝါးနဲ့ မှတ်မိတဲ့အဖေဆိုတာလေ ညမိုးချုပ်ကို လိုင်းကားတိုးစီးရင်း အင်ဂျင်နီယာ ဆိုက်ဝတ်စုံနဲ့ အလုပ်လုပ်နေရတုန်းတဲ့ ဝမ်းနည်းလိုက်တာဗျာ….

ခုချိန်ထိ ဘာပဲပေးရပေးရပါ အဖေကို ပြန်ရမယ်ဆို လိုချင်တုန်းပဲ လွမ်းတယ် ဘယ်တွေရောက်ပြီး ဘယ်အရပ်ဒေသမှာ မိဘတာဝန်လွန်စွာကျေပွန်နေပြန်ပြီလဲနော်…

အလုပ်က Apr မှာ စလုပ်တာ Agency မှာ လုပ်နေရာက inhouse ကို June မှာ ပြောင်းရတယ် နှစ်ကုန်တော့ UpWork ကနေ Permanent ဖြစ်သွားတယ်ပေါ့။ ပြဿနာက တနှစ်ပြည့်ခါနီးမှာစတာပဲ Product က Launch ဖြစ်ဖို့ အဝေးကြီးလိုသေးတယ် Feature တွေက မစုံသေး Design တွေက ခဏခဏပြင်နဲ့ စမ်းမဆုံး ထည့်မဆုံး အကုန်လုံး ပွယောင်းယောင်း codeတွေနဲ့ ရှေ့ code လဲ ဖျက်မရ နောက် code ကလဲ ပြင်လွယ်ပြောင်းလွယ်တွေ လိုက်ရေးရနဲ့ တော်တော် အဆင်မပြေနေပါဘူး။ income ကလဲ မဝင်သေးတော့ အလုပ်ရှင်ခမျာ လစာတောင် (၇)ရက်လောက်နောက်ကျပြီးမှ ပေးနိုင်တော့တာမျိုးဖြစ်လာတယ်။ မတိုင်ခင်မှာလဲ လူလျှော့ဖို့တော့လိုနေပြီ ပြောနေတာမျိုးတွေ ကြားရတယ်။ ကိုယ်က project သုံးခုလောက်ကို ကိုင်ရတော့ လုံးဝ လျှော့ရင် ကိုယ်မပါဘူးပဲထင်တာ မထင်မှတ်ပဲ ကိုယ်က ထိပ်ဆုံးကပါသွားရော..

ကျနော့်အမျိုးသမီးနဲ့ စတွေ့တုန်းကလည်း stress တွေ မိသားစု ကိစ္စတွေ အချစ်ရေး အဆင်မပြေမှုတွေနဲ့မလို့ ကျနော့်မှာ အလုပ်ထွက်ထားတယ်။ သူမ ဖေးမမှုတွေနဲ့ အစကပြန်ကြိုးစားပြီး Senior Dev, Lead Dev အဖြစ်နဲ့ Corporate Company ကြီးတခုမှာလုပ်နိုင်ခဲ့တယ်။ Coup နဲ့ Covid နဲ့ ကြုံလာတော့ WFH လုပ်ချင်လို့ အလုပ်ထွက်ခဲ့တယ် Remote Singapore အလုပ်တွေ Join တာ Stress ပိလို့ ပြုတ်ပြန်ရော တကယ်တော့ မင်္ဂလာဆောင်ဖို့အကုန် စီစဉ်ပြီးသား ဖိိတ်စာမှာတောင် အလုပ်ထည့်ရိုက်ထားတာကနေ အကုန်ပြန်ပြင်ခဲ့ရ အလုပ်မရှိပဲ မင်္ဂလာဆောင်ဖို့ စီစဉ်ခဲ့ရတယ်။ ရည်းစား စဖြစ်တော့လဲ အလုပ်လက်မဲ့ မင်္ဂလာဆောင်ခါနီးလဲ အလုပ်မရှိနဲ့ ကံကောင်းလို့ အကိုတစ်ယောက်က ချိတ်ဆက်ပေးလို့ Upwork remote အလုပ်တခုမှာ အလုပ်ပြန်ရတယ် အခု တနှစ်လောက်ပဲကြာတယ် သားလေးမွေးပြီးခါမှာလဲ ထပ်ပြုတ်ပြန်ပြီ အလုပ်လက်မဲ့ ဖေဖေဖြစ်ပြန်ပြီဗျာ..

အမျိုးသမီးရဲ့ အားပေးမှုတွေနဲ့ မပြိုလဲဘူးဗျာ ကျနော်ပြန်ပြီး အလုပ်တွေရှာဦးမယ်.. လျှောက်ဦးမယ်…

ဟိန်းသူရ
May 18 2023

• Go to /ios folder inside your Project.
• Delete Podfile.lock (YourPoject/ios/Podfile.lock)
• run cmd pod repo remove trunk

Now you have removed the pod completely. Now run

Here you have to do it according to the chip of your Mac, here I have given for both. thanks, @Kamal Panara for identifying this

For Intel chip users

Run pod install --repo-update

(Make sure your cd into the iOS directory of the flutter app) For M1 chip Users

install ffi first (if not) In regular terminal using command:

sudo arch -x86_64 gem install ffi

then run

arch -x86_64 pod install --repo-update

Note if you are getting an error of

[!] CocoaPods could not find compatible versions for pod "cloud_firestore":
  In Podfile:
    cloud_firestore (from `.symlinks/plugins/cloud_firestore/ios`)

Specs satisfying the `cloud_firestore (from `.symlinks/plugins/cloud_firestore/ios`)` dependency were found, but they required a higher minimum deployment target.

[!] Automatically assigning platform `iOS` with version `9.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.

now go to the podfile at line just uncomment the line and make it similar like below.

platform :ios, '12.0'

Now re-run this cmd.

arch -x86_64 pod install --repo-update

Now this time it will work fine.

now run

flutter clean

then

flutter run

enjoy.

About This Mac -> Storage -> Manage -> Developer
And deleted all the contents there

data from https://gist.github.com/mael/e3d9cd77a43347091d5c3894ce4e22c7

Solution “Unable to boot the Simulator”

sudo mkdir /private/tmp

sudo chmod 1777 /private/tmp

Other basic command

xcrun

xcrun simctl list devices //to list all simulators

xcrun simctl delete // to delete specific device

xcrun simctl delete unavailable // to remove old devices for runtimes that are no longer supported

Delete and clean

xcrun simctl shutdown all

xcrun simctl delete $(xcrun simctl list | grep -o ‘[0–9A-F]{8}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{4}-[0–9A-F]{12}’ | xargs)

xcrun simctl delete unavailable

xcode

sudo xcode-select — reset

To delete devices go here:

~/Library/Developer/CoreSimulator/Devices

Simulator

Defautl open /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/

Launch multiple simulators

find simulator id’s from the ‘xcrun simctl list’ command

xcrun simctl boot 12F3C6FB-1A8A-4D20–922F-2DB485F58F0F

xcrun simctl boot BE53CBFF-4900–4F10-A1D4-B451AB4C9E7E

open /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/

From Xcode project

1. Go to Window > Devices and Simulators, delete all the simulators, all of them.
2. Clear /Library/Developer/CoreSimulator/ folder.
3. Return to Xcode and install the required simulators.

#SharingIsCaring!

HTTP Overview (Mozilla)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

Introduction to Networking by Dr.Charles R Severance

https://www.amazon.com/Introduction.../dp/1511654945/

Chrome Developer Tools Overview (Google)

https://developer.chrome.com/docs/devtools/overview/

Firefox Developer Tools User Docs (Mozilla)

https://firefox-source-docs.mozilla.org/devtoo.../index.html

Getting Started with Visual Studio Code (Microsoft)

https://code.visualstudio.com/docs

HTML Elements Reference (Mozilla)

https://developer.mozilla.org/en-US/docs/Web/HTML/Element

The Form Element (Mozilla)

https://developer.mozilla.org/.../docs/Web/HTML/Element/form

What is the Document Object Model? (W3C)

https://www.w3.org/TR/WD-DOM/introduction.html

ARIA in HTML (W3C via Github)

https://w3c.github.io/html-aria/

ARIA Authoring Practices (W3C)

https://www.w3.org/TR/wai-aria-practices-1.2/

Learn more​

Here is a list of resources that may be helpful as you continue your learning journey.

CSS Reference (Mozilla)

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference

HTML and CSS: Design and build websites by Jon Duckett

https://www.amazon.com/HTML-CSS-Design.../dp/1118008189/

CSS Definitive Guide by Eric Meyer

https://www.amazon.com/CSS-Definitive.../dp/1449393195/

ကျနော့်ရုံးက DIA လိုင်းတွေချိတ်ထားတော့ Internet သုံးရတာ အဆင်ပြေတယ် အိမ်ပြန်ရောက်မှ Code ရေးဖို့ကြိုးစားတဲ့ အခါမှာတော့ ပြဿနာစတက်ပါပြီ Composer ကို ခေါ်မရတာနဲ့ Bitbucket ကို ဝင်မရရတာနဲ့ Singapore Server တွေဆို ချိတ်လို့မရရတာနဲ့ စိတ်အရမ်းရှုပ်ရပါတယ် OutLine ကို သုံးဖို့ တခြားသူတွေပြောပေမဲ့ ကျနော့် Laptopမှာ သွင်းလို့မရဘူး ကျနော်ရုံးက စက်ထဲမှာတော့ Outline က ကောင်းကောင်းသုံးလို့ရတယ် အိမ်က Ubuntu စက်မှာ VPN ချိတ်ဖို့လိုလာပြီဆိုတော့ Warp 1.1.1.1 ကိုများသုံးလို့ရမလားလို့ သုံးကြည့်တာအဆင်ပြေသွားလို့ Information လေး မျှဝေပေးချင်ပါတယ်။

https://developers.cloudflare.com/warp-client/setting-up/linux

အပေါ်ကလင့်မှာ အပြည့်အစုံတွေ့ရမှာပါ။ ကျနော်ကတော့ မြန်မာလို့Content ရှိစေချင်လို့ ထပ်ပြီးရေးထားလိုက်ပါမယ်။

ပထမဆုံး Linux Desktop Client သွင်းမယ်ပေါ့ဗျာ

Curl နဲ့ ပထမဆုံး Cloudflare Client package သွင်းကြမယ်

curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo apt-key add -

ရမရ အောက်က Cmd လေးကို Run ကြည့်လိုက်ဗျာ

echo 'deb http://pkg.cloudflareclient.com/ <RELEASE> main' | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

Release နေရာမှာ ကိုနဲ့ ကိုက်တဲ့ Versionကို ထည့်ပေးလိုက်ပါ ကျနော်က တော့ 20.04 ဆိုတော့ focal ကို ရွေးလိုက်တယ်

echo 'deb http://pkg.cloudflareclient.com/ focal main' | sudo tee /etc/apt/sources.list.d/cloudflare-client.list

ပြီးတဲ့အခါ sudo apt-get update ပေါ့ ပြီးရင် Cloudflare warp သွင်းလိုက်ပါ။

sudo apt-get update && sudo apt-get upgrade && sudo apt install cloudflare-warp

yum based OS မှာ ဆိုရင်တော့

sudo yum install cloudflare-warp

ပြီးတဲ့အခါ Register လုပ်ရမဲ့ cmd က တော့

warp-cli register

Connect လုပ်တဲ့ အခါမှာတော့

warp-cli connect

အလုပ်လုပ်မလုပ်စစ်ဖို့ကတော့ အောက်က ကောင်လေး ထပ် Run ကြည့်ပါ

curl https://www.cloudflare.com/cdn-cgi/trace/

ဒါဆို

warp=on

ဖြစ်နေမယ်ခင်ဗျာ့ အမြဲ ဖွင့်ထားချင်ရင်

warp-cli enable-always-on

ဒီလောက်ဆိုသုံးလို့အဆင်ပြေမယ် ထင်ပါတယ်။ နောက်တစ်ခေါက် စက် ပိတ်ပြီး ပြန်ဖွင့်တာဖြစ်ဖြစ် Internet line ပြောင်းတာ ချိန်းတာဖြစ်ဖြစ်

warp-cli connect

ပြန်ခေါ်ကြည့်ပေးလိုက် အဲ့တာ success ဆိုရင် WARP 1.1.1.1 ဖွင့်ပြီးပြီပေါ့ဗျာ။

အင်တာနက်ပိတ်ခံရခြင်း ဘေးအန္တရာယ်မှ ကင်းဝေးပါစေ။ လူ့အခွင့်အရေး ပိတ်ဆို့မှုများ ပပျောက်ပါစေဗျာ။

Bye for now

Thomaz

Sr. Software Engineer