Automating published Flexdashboard to embed into an Iframe

I would also like to understand If I automate the publishing of my flexdashboard using schedule of RStudio connect then how can I automate rmarkdown::render() each time to generate the updated HTML file.
Because the URL for the html file got by rmarkdown:: render() option takes the port of Rserver i.e 8787 below is the link
http://ec2-15-185-51-107.me-south-1.compute.amazonaws.com:8787/files/Flexdashboard/forecast.html
whereas Rstudio connect takes the port 3939
Please help me to understand this. Is there any other way in which the schedule static flexdashboard can be automated to produce a html file that could be embedded into an iframe
Thanks

Can someone help me on above question

Thanks

Sorry, I'm not sure I understand the problem.

The RStudio Connect schedule just rerenders the HTML and should completely hide the render() call form you - I'm not sure where the port numbers come into this.

Is this more about RStudio rather than RStudio Connect?

Sorry - confused - but happy to try to help!

@slodge Thanks for the reply,
I would be using RStudio Connect for publishing my flexdashboards on a schedule basis. The published dashboard which is generated by RStudio connect needs to be embedded in another website using Iframe. I am stuck at this part.
My dashboard http://ec2-15-185-51-107.me-south-1.compute.amazonaws.com:3939/connect/#/apps/1/access/1 needs to be embedded using Iframe.
How can I do this

Thanks and waiting for the reply

@slodge Can you please help me with this!

I'm afraid I still have no idea what you are talking about around your ports - and sending links to private ec2 instances isn't something I can see inside - sorry

My gut feels like all you want to do is to use the "Open solo" RStudio Connect views - and I think these already have headers setup so that they can be embedded in iFrames... however, I'm confused about the "port" setup - so not sure I can help. If you want to host on port 80 and 443, I'm not sure why you have your server setup on 3939... (but 3939 should still work - it's just not the normal http setup)