Demo · moontaeyang.com learning portal

This document treats this site(moontaeyang.com) itself as an Azure demo and explains which services it uses, how they are composed, and why it was designed this way from the perspective of engineers who want to build it themselves.

At a Glance

moontaeyang.com is a personal learning portal where AI automatically generates and publishes content daily/weekly. On top of one static web hosting service(Static Web Apps), two scheduled AI agents(Container Apps Jobs) generate and attach content. The key themes are serverless · keyless(no secrets) · schedule-based · static-first.

Front end(public serving): Azure Static Web Apps (Standard) — global CDN, free TLS, custom domain, social login.
Back end(content generation): 2 Azure Container Apps Jobs(daily/weekly cron) + Azure OpenAI(keyless) + Storage($web accumulated storage).
Static content(labs/demos): HTML from the repository is included in the portal shell and deployed together.
Notifications: Telegram Bot.

Architecture

                                  ┌──────────────────────────────────────┐
   User(browser) ──HTTPS──▶        │   Azure Static Web Apps (Standard)    │
   moontaeyang.com                │   - Global CDN + free TLS certificate │
                                  │   - Custom domains(moontaeyang.com,www)│
   Social login ──/.auth/*──▶      │   - Built-in auth(Google·GitHub·Kakao OIDC)│
                                  │   - Static file serving + SPA fallback │
                                  └───────────────▲──────────────────────┘
                                                  │ swa deploy(rebuild entire portal)
                 ┌────────────────────────────────┴────────────────────────────────┐
                 │                                                                  │
   ┌─────────────┴─────────────┐                                  ┌─────────────────┴───────────────┐
   │ Container Apps Job         │  Daily 06:00 KST                  │ Container Apps Job              │  Every Mon 06:00 KST
   │ engitdaily-job             │  (cron 0 21 * * *)                │ azwhatsnew-job                  │  (cron 0 21 * * 0)
   │  1) Collect HN/RSS         │                                  │  1) Collect Azure Updates RSS   │
   │  2) Azure OpenAI summarize/│◀── Managed Identity(keyless) ──▶ │  2) Azure OpenAI summarize     │
   │     generate               │                                  │                                  │
   │  3) Accumulate in Storage  │                                  │  3) Accumulate in Storage       │
   │     $web                   │                                  │     $web                         │
   │  4) Rebuild/deploy portal  │                                  │  4) Rebuild/deploy portal       │
   │  5) Telegram notification  │                                  │  5) Telegram notification       │
   └─────────────┬─────────────┘                                  └─────────────────┬───────────────┘
                 │                                                                  │
   ┌─────────────▼─────────────┐                                  ┌─────────────────▼───────────────┐
   │ Storage(engit) $web        │  Accumulates past daily pages     │ Storage(azwn) $web              │  Accumulates past weekly pages
   │ engitdailyst…              │  (permanent "warehouse")          │ azwhatsnewst…                   │  (permanent "warehouse")
   └────────────────────────────┘                                  └─────────────────────────────────┘

   Shared: each agent has a dedicated ACR(image) · User-Assigned Managed Identity(UAMI) · Container Apps Environment.
   Static sections(/labs, /demos) are included from repository HTML into the portal shell and published with every deployment.

Azure Services Used (by Role)

Service	Role	Notes
Azure Static Web Apps (Standard)	Public web serving, custom domain, TLS, social login	Standard is required for custom authentication/OIDC
Azure Container Apps Job	Generates content as scheduled(cron) batches	0 instances normally → billed only when running(serverless)
Azure OpenAI (gpt-5.4)	Article/summary/vocabulary generation	Keyless: called via Managed Identity + RBAC
Azure Storage(Blob, `$web`)	Accumulated storage for generated pages(warehouse) + md history	Uses the static website container `$web`
Azure Container Registry(ACR)	Stores agent container images	Cloud build via `az acr build`
User-Assigned Managed Identity	ACR pull · Storage read/write · OpenAI call permissions	Core of zero-secret operations
Telegram Bot API(external)	Publication completion notifications	Token only as Job environment variable(secret)

Microsoft Entra ID(app registration) is used to integrate GitHub/Google/Kakao OAuth apps with SWA authentication for social login.

Key Design Points (Why This Way)

1. Why Static Web Apps

The content is static HTML(daily/weekly generated pages), so there is no reason to run a server 24/7.
SWA provides global CDN + free TLS + custom domain + built-in authentication in one place → almost zero operational burden.
Cost: static hosting is effectively very inexpensive(for personal traffic), around the Free/Standard flat-rate level.

2. Why the Standard plan

Social login(custom OIDC providers, e.g., Kakao) is supported only in SWA Standard(Free limits you to built-in providers).
Google/GitHub are named providers, and Kakao is connected through customOpenIdConnectProviders(OIDC discovery).
Pitfall: the provider's client-id/secret app settings must exist for the /.auth/* endpoints to be mounted. Without them, everything returns 404.

3. Content "accumulation" and the clobbering problem (most important)

swa deploy replaces the entire site. There is no concept of "append".
Therefore, if you publish only "today's one article" each day, ① past articles disappear and ② other sections(weekly/labs) are deleted.
Solution: use each section's Storage $web as a permanent accumulated warehouse, and on every deployment reassemble both warehouses + portal shell + static sections in full before running one swa deploy. → Whoever deploys, the "entire portal" is always uploaded, so sections do not overwrite each other.
Assembly information is passed through the environment variable PORTAL_SECTIONS=engit-daily=<$web>;azure-daily=<$web>.

4. Static sections vs dynamic sections

Dynamic sections(/engit-daily, /azure-daily): generated by agents → accumulated in Storage $web → mirrored during deployment.
Static sections(/labs, /demos): repository HTML is included in the portal shell → carried along unchanged with every deployment(no agent/Storage required).
Both types are served from one SWA, while the deployment logic combines the "full static shell + dynamic section mirrors" and uploads them together.

5. Keyless operations

No connection strings/keys are used for Azure OpenAI or Storage access.
RBAC is assigned only to the Job's User-Assigned Managed Identity: Cognitive Services OpenAI User, Storage Blob Data Contributor(own storage), Storage Blob Data Reader(for mirroring the other storage), AcrPull.
In code, authentication uses a single DefaultAzureCredential() → no secrets remain in the repository.

6. Cron schedules use UTC

Container Apps Job cron is based on UTC. 06:00 Korea time(KST=UTC+9) = 21:00 UTC on the previous day.
Daily: 0 21 * * * · Weekly(Monday): 0 21 * * 0(Sunday 21:00 UTC = Monday 06:00 KST).

7. Security guardrails

Social login client-id/secret, Telegram tokens, and similar values are not committed to the repository; they exist only as SWA app settings/Job environment variables(secrets).
Blocking public access to Storage is recommended by default. However, if the agents read/write Blob through the public endpoint, they are blocked when publicNetworkAccess=Disabled → this demo uses RBAC protection while keeping public access enabled (in environments where policy enforces blocking, Private Endpoint + VNet integration is the standard approach. Front Door is for inbound acceleration and is not appropriate for this use case).

Data Flow

(A) User request flow 1. Browser requests moontaeyang.com → SWA returns static files from the global CDN(TLS automatic). 2. User clicks login → /.auth/login/<provider> → provider(Google/Kakao/GitHub) authentication → callback → session cookie. 3. SPA fallback: unmatched paths route to shell index.html(except /engit-daily/*,/azure-daily/*,/labs/*,/demos/*,/.auth/*).

(B) Content generation flow(agent, once per day/week) 1. Cron triggers the Job → container starts(image pulled from ACR). 2. Source collection(Hacker News API / Azure Updates RSS). 3. Generate articles, summaries, and vocabulary through Azure OpenAI(keyless). 4. Accumulate results in Storage $web(today's/this week's page + section index updates), and keep md history in Blob. 5. Portal rebuild: copy shell(+static sections labs/demos) + mirror the two dynamic sections from each $web → swa deploy. 6. Send a "publication complete + link" notification through Telegram.

Cost Overview (Approximate, Personal Traffic)

SWA Standard: flat rate(around $9/month) — includes custom authentication/domain.
Container Apps Job: normally 0 instances → billed only for tens of seconds to a few minutes of daily runtime(very small).
Azure OpenAI: charged by token usage — modest for roughly 6 articles/day and weekly summaries.
Storage/ACR: hundreds of MB scale → small cost.
Combined, expected to be single digits to low teens of dollars per month for personal operation(well within the $2500 per subscription budget).

Prices change, so verify actual charges with Azure Pricing/Cost Management(these figures are guidance only).

Build Sequence for Engineers (Summary)

Create SWA(Standard) + connect custom domains(moontaeyang.com, www) + DNS(A/ALIAS, TXT verification).
Social login: register Google/GitHub/Kakao OAuth apps → add an auth block to SWA staticwebapp.config.json(+ customOIDC for Kakao) → inject client-id/secret into SWA app settings(otherwise /.auth/* returns 404).
Agent infrastructure(1 set each, Bicep): ACR + UAMI + Container Apps Environment + Job(cron) + Storage($web static website enabled) + Azure OpenAI(deployment gpt-5.4).
RBAC: grant UAMI AcrPull · Cognitive Services OpenAI User · own Storage Blob Data Contributor · other Storage Blob Data Reader(mirror).
Image build/deploy: build image with az acr build → update Job(environment variables: PORTAL_SECTIONS, PORTAL_BASE_URL, SWA_DEPLOY_TOKEN(secret), etc.).
Deployment logic: at runtime, the container copies shell+static sections + mirrors dynamic sections + runs swa deploy.
Notifications: Telegram Bot token/chat-id as Job environment variables.
Add static sections: build /labs, /demos from Markdown to HTML and include them in the portal shell.

Common Roadblocks / Lessons Learned

/.auth/* returns 404 → provider app settings(client-id/secret) are missing. They are mounted after configuration.
Kakao login KOE004 → register the callback URI under Login Redirect URI, not "logout redirect", and enable OIDC.
Other sections disappear after deployment → swa deploy replaces the whole site. Rebuild the entire portal every time(PORTAL_SECTIONS mirror).
Job gets Blob write AuthorizationFailure → Storage publicNetworkAccess=Disabled. If policy enforces this, use Private Endpoint; otherwise public access Enabled + RBAC.
Cron runs at an unexpected time → remember it is based on UTC(KST-9h).

References

← All demos Portal home