Developing a Astrology webapp version 1.

Review and execution boundary

Application scaffolding and Azure custom-domain lesson, not validation of astrology or a live product.

Reviewed on 7 October 2026 against the official source snapshots linked below. The review is bounded editorial correction, not certification of every dependency, security property or cloud deployment. Historical setup commands and optional exercises were not executed. No cloud resources, third-party packages or external side effects were created. Old screenshots and unavailable private assets remain in the private recovery archive, not prerequisites for this lesson.

Developing and Deploying Basic Astrology Webapp and binding to AWS domain.

Website : www.astroyuga.com

Azure Webapp : https://astro.azurewebsites.net/

Git Hub : https://github.com/dinesh-coderepo/astrology

This version tests a deployment path: generate a placeholder with Replit AI, run it locally, deploy it to Azure App Service and connect a domain registered through AWS. The subscription features below are a roadmap, not capabilities demonstrated by the placeholder. This is a software-development record, not a validation of astrological predictions.

• Customer Perspective:

  • Access via phone or mobile for daily predictions
  • Push notifications or email for daily astrology insights
  • Login using Google (initially)
  • Customer-specific view
  • Features:
    • One-time overall life prediction
    • Daily suggestions and weekly forecasts
  • Daily predictions should be actionable and suggestive:
    • What color to wear
    • What mantra to say
    • Recommended poojas
  • 1 week free prediction with monthly payment options
  • Paid content visible only to subscribed customers
  • Future scope: mobile app version

• Technology Perspective:

  • Collate accurate astrology material
  • Research existing apps and implement successful flows
  • Integrate AI component (LLMs) for text-based content generation
  • Explore RAG (Retrieval-Augmented Generation) to integrate knowledge base with LLM

Initial Placeholder app Development with Replit AI

The two Replit screenshots document scaffolding and environment setup. The useful checkpoint is whether the generated app can run outside the agent's environment; that is why the next step moves the code into a local Cursor workspace before cloud deployment.

• Generating Initial Version:

  • Used Replit AI agent to create a placeholder app
  • AI executed and corrected code autonomously
  • Effective for small-scale projects

• Setup:

  • AI agent set up dependencies and installation
  • Iterative error correction
  • Suitable for small-scale projects

• Generated Code:

  • Available in Replit repo: AstroGuide

• Local Development:

  • Imported code to local Cursor environment
  • Set up app to run locally
  • Replit can generate a README.md with dependency information

• Deployment and hosting:

  • Initial version of the app is now ready , this is a placeholder version until all the other features are implemented and added.
  • Purchased the domain astroyuga.com in AWS.
  • Using the same approach as blogapp ,deploying to webapp using githubactions and then bind the domain to the webapp.
  • Binding of aws domain to webapp, I am doing this for the first time , will document the approach.

• CI and CD using github actions:

  • Integrated the github to the app service,

  • Git Hub Repo : https://github.com/dinesh-coderepo/astrology

  • Currently there is no need of .env file as we do not have keys as we needed for translation function in this blog.

  • Currently the app is running in https://astro.azurewebsites.net/

  • GitHub actions script which is used to deploy : workflow.yml

The app is hosted on Azure; registering its name through AWS does not move that hosting. Domain setup has three separate jobs: prove control of the name with a TXT record, route traffic with DNS, and bind a certificate so the custom hostname can use HTTPS. Read the validation and binding screenshots as different checkpoints in that process.

7. Domain binding to webapp:

   • In the webapp go to custom domains and add select Domain Provided as All other domain services leave remaining options as is.

   • Add the domain name in Domain section : astroyuga.com

   • For domain validatetion test the TXT value - copy it somewhere also you can export to CSV to local.

   • In AWS create a record with asuid as the record name , record type as TXT and add the value as the one you got from the webapp.

   • Same as above add the value of A by keeping record name as blank and record type as A

   • Validate in Azure portal once the records is added.

   • Add the binding after valildation, use App Service Managed Certificate to add this binding.

   • Also add another record for subdomain www. , add the record with asuid.www and add the value TXT copied (record type as TXT).

   • Enable HTTPS Only option in app service in Configuration tab to On

   • Domain binding is now complete and www.astroyuga.com is pointing to the webapp https://astro.azurewebsites.net/.

The final screenshot records the placeholder reached through the custom domain at the time of this walkthrough. It does not verify the planned login, payments, notifications or personalized content. Those features need their own implementation and tests before this becomes the subscription product described at the start.

Corrected contracts and failure analysis

Keep the domain tutorial while separating the speculative product roadmap from shipped capabilities. A registrar, DNS host, application host and certificate issuer are distinct roles; registering a name through AWS does not mean the application runs on AWS. For a root domain follow the current App Service A/TXT flow; for www configure its own CNAME/TXT as instructed. A TXT ownership record does not route user traffic.

Bind the verified hostname and its certificate, then test hostname coverage and HTTPS from a clean client. Preserve domain-verification records to reduce dangling-domain takeover risk and remove obsolete DNS records before releasing a hosting resource. Login, subscriptions, notifications and personalized content require separate authorization, consent and entitlement tests; a placeholder homepage proves none of them. The application must not represent generated astrological text as scientific or medical evidence.

Boundary exercise with solution

The asuid.www TXT record validates, but www does not open. What is missing?

Solution and reasoning

TXT proves control; it is not a routing record. Inspect the www CNAME (or supported routing alternative), propagation, App Service hostname binding and certificate. Test apex and www separately, including redirects, rather than interpreting a validation checkmark as full availability.

Source-backed review notes

• Set Up an Existing Custom Domain Name for Your App - Azure App Service | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “The following screenshot shows the default selections for a www.contoso.com domain. It shows a CNAME record and a TXT record to add.”
• Managed identities for Azure resources - Managed identities for Azure resources | Microsoft Learn — accessed 2026-10-07. Exact supporting passage: “A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Manual handling of secrets and certificates are a known source of security issues and outages. Managed identities eliminate the need for developers to manage these credentials. Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials.”